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