1 / 43

WS-Federation

WS-Federation. Jim Van Dyke Zhengping Wu. Partially adapted from workshop slides by Tony Nadalin (IBM) and Chris Kaler (Microsoft). Agenda . Introduction Trust Topologies Single Sign-out Attribute Services Pseudonym Services Active/Passive Profiles Summary and Conclusions Demo

sanne
Download Presentation

WS-Federation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WS-Federation Jim Van Dyke Zhengping Wu Partially adapted from workshop slides by Tony Nadalin (IBM) and Chris Kaler (Microsoft)

  2. Agenda • Introduction • Trust Topologies • Single Sign-out • Attribute Services • Pseudonym Services • Active/Passive Profiles • Summary and Conclusions • Demo • References

  3. What is Federation? • Federation • A collection of realms/domains that have established trust • The technology and business arrangements necessary to interconnect users, applications, and systems • Federated systems can interoperate across organizational and technical boundaries (i.e., various operating systems or security platforms)

  4. Federated ATM Network Account Number and PIN Visiting Bank Network Funds Network of Trust Home Bank Network

  5. WS-Federation • Primary Goal: “Single Sign-On” access across trust domains using identities from the different domains • WS-Federation defines a model for this by building on the WS-* security specifications: • Brokering trust • Sign out messages • Attribute service • Pseudonym service

  6. WS-Federation Terms • Authorities • Security Token Service (STS) – Web service that issues security tokens; makes assertions based on evidence that it trusts to whoever trusts it • Identity Provider (IP) – Entity that acts as an authentication service to end requestors (an extension of a basic STS) • Principles • Requestor • Resource • Other Services

  7. One Protocol, Multiple Bindings • Common protocol (WS-Trust) • Two “profiles” of the model are defined • Smart/Active clients (SOAP) • Passive clients (Browser – HTTP/S) • Supporting services (attribute/pseudonym/…) HTTP messages HTTPReceiver Security Token Service SOAP Receiver SOAP messages

  8. Trust Topologies • Federation approach must address different trust topologies • Model existing business practices • Leverage existing infrastructure • Sample topologies • Direct trust • Exchange • Validation • Indirect trust • Delegation

  9. Direct TrustToken Exchange IP/STS IP/STS Trust Get accesstoken Get identity token 1 2 Resource Requestor 3

  10. Request token Acquire policy Return token Return policy Request token Return token Send secured request Return result Direct Trust Flow Requestor Service Requestor IP/STS WS Service Service IP/STS

  11. Direct TrustToken Validation IP/STS IP/STS Trust Get identity token Get accessverification 1 3 Resource Requestor 2

  12. Trust Trust Indirect Trust IP/STS B IP/STS IP/STS A C 1 2 Resource Requestor 3 C trusts B which vouches for A who vouches for client

  13. Delegation IP/STS IP/STS IP/STS Trust Trust 1 2 4 Resource Resource 3 5 Requestor

  14. Single Sign-Out IP/STS … Requestor IP/STS 2 … 2 1 2 Resource

  15. Sign-Out Message <S:Envelope> <S:Header> ... <wsu:Timestamp wsu:Id="ts"> ... </wsu:Timestamp> <wsse:Security> <!-- Signature referecing IDs "ts" & "so" --> ... </wsse:Security> </S:Header>

  16. Sign-Out Message (cont.) <S:Body> <wsse:SignOut wsu:Id="so"> <wsse:SignOutBasis> <wsse:UsernameToken> <wsse:Username>NNK</wsse:Username> </wsse:UsernameToken> </wsse:SignOutBasis> </wsse:SignOut> </S:Body> </S:Envelope>

  17. Requesting Sign-Out Message <wsse:RequestSSOMessages> <wsa:EndpointReference> <wsa:Reference>http://business456.com/SSO </wsa:Reference> </wsa:EndpointReference> <wsse:UsernameToken> <wsse:Username>Nicholas</wsse:Username> </wsse:UsernameToken> </wsee:RequestSSOMessages>

  18. Attribute Service • Scenario: You ask a weather service for the current weather (or visit a weather site); it provides a personalized response because it knows your zip code • Why it worked: • Policy indicated an attribute service • Identity information was used to find zip code • Weather service was authorized to access zip code (opt-in) • Specification defines the concept of an attribute service but not a specific interface

  19. Attribute Service Example • Attributes may have associated scopes • Each attribute may have its own access control and privacy policy

  20. Attribute Scoping Zip: 12309 FN: Fred ID: 3442 Nick: Freddo ID: FJ454 Nick: Fredster ID: 3-55-34 … (fabrikam123.com) (business456.com) (example.com) Model allows for attributes to be scoped

  21. Attribute Discovery • Open design model • Any attribute store can be used • Integration with legacy systems • Discovery via policy • Requestor’s policy  attribute service • Attribute service has its own policy • Communication is governed by this policy • UDDI is an example store

  22. Policy Policy Attribute Discovery Attribute Service 3 4 “Get FN” 2 Requestor Resource 1

  23. Attribute Example Attribute Service IP/STS IP/STS Trust Trust Zip: 12309 FN: Fred … 4 1 2 3 Resource Requestor

  24. Protecting Identity • Single sign-on also needs to • Prevent identity tracking • Provide anonymity • Other forms of identity tracking still exist: • Address • Phone number • Credit card • Social security number

  25. Identity Approaches • One federation model • Multiple identity approaches • Static identifier, possibly obfuscated • Static per-target identifier • One-time identifier

  26. Trust Static Identifier Example IP/STS “Fred”  “Fred@STS” 1 Resource Requestor 2 “Fred@STS”

  27. Trust Trust Static Per-Target Example IP/STS “Fred”  “A123” “Fred”  “B456” 1 3 Resource Resource 2 4 “A123” “B456” Requestor

  28. Pseudonym Service • This service provides a mechanism for associating alternate identities • Pseudonyms represent alternate identities • Depends on scope of request • Subject to authorization control • Can be integrated with IP/STS

  29. Policy Policy Pseudonym Discovery Pseudonym Service 3 4 2 Requestor Resource 1

  30. Pseudonym Example 1 B456.com Pseudonym Service B456.com IP • Service sets pseudonym for its domain Trust “Fred”  “A123@B456.com” “A123@B456.com”  “Freddo@F123.com” 1 3 Requestor Resource 2 “A123@B456.com”

  31. Pseudonym Example 2 B456.com Pseudonym Service B456.com IP • Service fetches pseudonym for its domain Trust “Fred”  “B456@B456.com” “B456@B456.com”  “Freddo@F123.com” 1 3 4 Requestor Resource 2 “B456@B456.com”

  32. Pseudonym/STS Integration • Pseudonym & STS can work together • Single physical service • Separate but tightly coupled services Token Request

  33. Pseudonym Example 3 B456.com Pseudonym Service B456.com IP • Use pseudonyms to obtain initial token Trust 2 “Fred”  “Freddo@F123.com” “Fred”  “Freddo@F123.com” 1 Requestor Resource 3 “Freddo@F123.com”

  34. Active (Smart Client) Profile • Describes options for SOAP-enabled clients • Varied models based on policy • Business needs • Inter-organization relationships • Regulations • Strong authentication of all requests

  35. Request token Return token Request token Return token Send secured request Return secured response Example Flow (SOAP) Requesting Service Requestor’s IP/STS Target Service Target’s IP/STS Acquire policy

  36. Passive Profile • Describes options for browser clients • URL-only • GET, POST body • Cookies (a custom caching mechanism) • Uses redirection to effect messages • Should conform as closely as possible to WS-Trust protocols

  37. Redirect to resource’s IP/STS Detect realm Redirect to requestor’s IP/STS Login Return identity token Return resource token Return secured response Example Flow (Browser) Requesting Browser Requestor’s IP/STS Target Resource Target’s IP/STS Get resource

  38. WS-FederationFeatures • Cross-domain trust federation • Generic token acquisition • Enables different trust topologies • Single Sign-On / Sign-Off • Identity Protection and Privacy • Attributes and Pseudonyms • End-to-end security • No HTTPS required

  39. WS-FederationSummary • Integrates with existing infrastructures • Business model • Token formats • Attribute stores • Directory services • Together with the other WS-* specifications, provides a rich fabric for building secure, reliable, transacted systems across federation boundaries

  40. Basic Trust Federation Demo • 3 Participants: Client, Service, STS • No trust relationship between Client (requestor) and Service (resource) • Client and Server trust the STS • Uses WSE 2.0: Supports WS-Security, WS-Policy, WS-SecurityPolicy, WS-Trust, WS-SecureConversation, and WS-Addressing.

  41. Optional Extensions of Demo Token Validation Mapping with WS-Addressing

  42. Primary References • WS-Federation Feedback Workshop • These workshop slides provide an overview of WS-Federation. http://www-106.ibm.com/developerworks/offers/WS-Specworkshops/ws-fed200311.html • Federation of Identities in a Web Services World • This whitepaper discusses using WS-Federation to federate identities across trust domains. http://msdn.microsoft.com/ws-federation/

  43. Secondary References • Web Services Federation Language (WS-Federation) • This is the complete WS-Federation specification. http://msdn.microsoft.com/ws/2003/07/ws-federation/ • WS-Federation: Active Requestor Profile • This is the specification for active profiles in WS-Federation. http://msdn.microsoft.com/ws/2003/07/ws-active-profile/ • WS-Federation: Passive Requestor Profile • This is the specification for passive profiles in WS-Federation. http://msdn.microsoft.com/ws/2003/07/ws-passive-profile/

More Related