CIS13: Federation Protocol Cross-Section
- 1. 1
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Federation Protocols:
A Cross-Section
David Waite
Technical Architect, Ping Labs
1
- 2. 2
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Who am I?
• David Waite
• In Identity Space for 10 years
• With Ping Labs group
Mad Scientist and Mad Science Facilitator
- 3. 3
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Alternative Talk Name #1
Build your own Federated Identity Protocol
- 4. 4
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Rejected!
• Do not want to encourage people to build
their own protocols!
• Confusing with other aspects of talk
- 5. 5
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Alternative Talk Name #2
SAML 101: The Speed Run
- 6. 6
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Rejected!
• But, not just going to on just one protocol
– SAML 2.0
– WS-Federation
– OpenID Connect
– and friends
• all at once
- 7. 7
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Federation Protocols: A Cross-Section
• What is Federated Identity
– Thinking about things at a higher level
• How protocols solve the problem similarly
– The individual steps they all take
• How protocols differ, and why
- 8. 8
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Caveats
• Not covering parts outside Authentication
– Single log out, Name Identifier Mapping, etc.
• Will be conflating what is possible and
what is deployed
• Calling Everything Identity Provider/
Service Provider
• Will be jumping around a little bit
- 11. 11
Copyright ©2013 Ping Identity Corporation. All rights reserved.
(Local) Login Process
• Detect need to authenticate user
• Authentication Request(Challenge)
• Receive Response
• Validate Response
• Success!
- 12. 12
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Web SSO
• Web SSO
– Share identity from Identity Provider to Service
Provider
– In the context of a Web Browser
– Speaking HTTP and understanding HTML
– Requiring no additional client code
- 13. 13
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Local Login Process (Redux)
• Detect need to authenticate user
• Authentication Request (Challenge)
• Receive Response
• Validate Response
• Success!
- 14. 14
Copyright ©2013 Ping Identity Corporation. All rights reserved.
SAML SP Login Process
• Detect need to authenticate user
• Send AuthnRequest
• Receive AuthnResponse
• Validate AuthnResponse
• Success!
- 15. 15
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Web SSO
• Web SSO is an abstraction
– of authentication mechanisms
• A Service can delegate user authentication
– To another party they trust
• An authentication mechanism Proxy
- 16. 16
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Details
• The Identity Provider (IDP) is
authenticating on behalf of a user
to a Service Provider (SP):
– Challenge goes to another server
– Response comes back from that server
• Validation of server response leads to user
authentication on the Service Provider
• SP not exposed to actual authentication
- 18. 18
Copyright ©2013 Ping Identity Corporation. All rights reserved.
In the beginning...
• In the beginning, there was SAML
– proprietary systems for doing Web SSO
required selling,deploying solutions to both side
• Now could be labelled enterprisy tech
– XML
– X.509 certs/keys
– SSL deployment
– Partners configured via admins
- 19. 19
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Issues with XML
• XML is/was
– cross-language with lots of tool support
– extensible
– buzz-worthy
• But the XML signing/encryption support is
– hard to implement (canonicalization)
– spotty across languages
– difficult to verify is secure
- 20. 20
Copyright ©2013 Ping Identity Corporation. All rights reserved.
OpenID 1/2
• Heavily influenced by blogging community
– low cost shared hosting
• No SSL requirement
• Option for relying party to be stateless w/o crypto
• User Centric
– discovery of Identity Providers (OPs) built-in
– dynamic connections with no manual setup
- 21. 21
Copyright ©2013 Ping Identity Corporation. All rights reserved.
OpenID 1/2
• Symmetric keys per partner
– negotiated via DH
– similar security model to SSH
• Query parameter protocol
– invented canonicalization, signing mechanism
– swiped by OAuth 1
- 22. 22
Copyright ©2013 Ping Identity Corporation. All rights reserved.
WS-Federation
• WS-Federation
– SAML protocol has additional baggage
– SAML assertions are worth using
– Something more STS/WS-* compatible
• Replaces protocol bits with query strings
• Still sends XML SAML tokens
• Implementations usually focus on
interoperability with Microsoft
- 23. 23
Copyright ©2013 Ping Identity Corporation. All rights reserved.
OpenID Connect
• Built on top of OAuth 2
– Service Provider is OAuth 2 client
– Identity Provider (OP) is Authorization Server
• Like OpenID 1/2
– discovery of Identity Providers (OPs) defined
– connections without manual setup possible
• Encourages per-domain setup
– Facebook Connect model
- 25. 25
Copyright ©2013 Ping Identity Corporation. All rights reserved.
OpenID Connect
• More modular design
– built on top of OAuth 2, WebFinger, JW*
• Basic/Implicit Client
– use a slice through dependent specs
• Dynamic Clients
– require WebFinger, client registration, JWK
• Profile of OAuth 2
- 27. 27
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Request Commonalities
• Usually requests are not signed/encrypted
– expensive signature for anonymous users
• DDoS opportunity
– Choices usually negotiated out-of-band
– Response typically references choices made
• relayed state
- 28. 28
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Request Differences
• OAuth bundles several things into the
request process
– Discovery, metadata/key lookup/provisioning
• SAML, WS-Federation nearly always have
partners provisioned beforehand
• SAML requests are not addressed to an
Identity Provider
- 29. 29
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Response Commonalities
• User attributes and authentication
information
• Sent to Service Provider, verifiable via
– Front channel signed message
– Back channel (SAML and OpenID 2)
- 30. 30
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Response Differences
• SAML 2 supports encryption
– protect information from user/third parties in
browser channel
• Asymmetric keys support non-repudiation
• OpenID 2 may require network discovery
to process response
– Authenticated ID != requested ID
- 31. 31
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Validation of Response
• Validate message is well-formed
• Decrypt/validate signatures
• Verify information
– is it acceptable for the IDP to make these
claims?
• Map to any local account
• Create session (and store cookie)
- 33. 33
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Discovery
What if you had more than one way to log
in locally?
- 34. 34
Copyright ©2013 Ping Identity Corporation. All rights reserved.
IDP Discovery
• Federated Web SSO
– more than one Identity Provider exists
– need to figure out which one to use
– How to do that when you don t know who the
user is yet?
- 35. 35
Copyright ©2013 Ping Identity Corporation. All rights reserved.
IDP Discovery
• No perfect strategy!
• Eventually, you have to either
– ask user to pick from list
– fail with user instructions
- 36. 36
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Option #1
User picks from list of all options
- 37. 37
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Option #1
• What about when you have too many
options?
• Identity providers may be your customers
• can you publicize your customer list?
- 38. 38
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Option 2
• OpenID - ask your user who they are first
- 39. 39
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Option 2
• User may not know what is appropriate to
type into the field
– Most services aren t willing to take on user
education for a new authentication system
• Two-step login process
• Assumes a single place to send all users
matching pattern
- 40. 40
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Option 3
• Cardspace had an Active Component
– Knew where you could log in
– Services specified their needs for an IDP
- 41. 41
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Option 3
• Requiring active component to work limits
adoption
• Users still had to add Identity Providers
– But their employer could do this for them
- 42. 42
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Other options
• Unique IDP per distinct URL
– https://companyname.servicedomain.com
• Look at source IP address as hint
• Firewall/Profile adds HTTP header
• Portal links hint via URL parameters
• Identity-Provider-Initiated only
• Must do IDP initiated once, then set cookie
- 43. 43
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Account Chooser
https://www.accountchooser.com/
- 44. 44
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Pro Tips
• Approaches typically aren t protocol specific
- mix and match
• Cache choice on success for use later
• SAML describes sharing previous decisions
across domains via browser/cookie cache
– WAYF, SAML Common Domain
• Make an explicit choice on fallback strategy
– give user list, or fail with user instructions