SlideShare a Scribd company logo
1
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Federation Protocols:
A Cross-Section
David Waite
Technical Architect, Ping Labs
1
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
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Alternative Talk Name #1
Build your own Federated Identity Protocol
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
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Alternative Talk Name #2
SAML 101: The Speed Run
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
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
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
9
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Basics of Federated Identity
9
10
Copyright ©2013 Ping Identity Corporation. All rights reserved.
The Venerable Login Form
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
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
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
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
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
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
17
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Protocol Differences
17
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
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
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
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
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
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
24
Copyright ©2013 Ping Identity Corporation. All rights reserved.
OpenID Connect
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
26
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Protocol Specifics
26
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
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
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
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
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)
32
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Final Detour: Discovery
32
33
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Discovery
What if you had more than one way to log
in locally?
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
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
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Option #1
User picks from list of all options
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
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Option 2
• OpenID - ask your user who they are first
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
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
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
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
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Account Chooser
https://www.accountchooser.com/
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

More Related Content

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
  • 9. 9 Copyright ©2013 Ping Identity Corporation. All rights reserved. Basics of Federated Identity 9
  • 10. 10 Copyright ©2013 Ping Identity Corporation. All rights reserved. The Venerable Login Form
  • 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
  • 17. 17 Copyright ©2013 Ping Identity Corporation. All rights reserved. Protocol Differences 17
  • 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
  • 24. 24 Copyright ©2013 Ping Identity Corporation. All rights reserved. OpenID Connect
  • 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
  • 26. 26 Copyright ©2013 Ping Identity Corporation. All rights reserved. Protocol Specifics 26
  • 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)
  • 32. 32 Copyright ©2013 Ping Identity Corporation. All rights reserved. Final Detour: Discovery 32
  • 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