CIS13: Federation Protocol Cross-Section
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

CIS13: Federation Protocol Cross-Section

on

  • 369 views

David Waite, Technical Architect, Ping Identity ...

David Waite, Technical Architect, Ping Identity
We will take the federation protocols of SAML, OpenID, WS-Federation and OpenID Connect and attempt to break them down into common concerns. We will then examine the different approaches taken to address these concerns, the rationale and the trade-offs which resulted.

Statistics

Views

Total Views
369
Views on SlideShare
369
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

CIS13: Federation Protocol Cross-Section Presentation Transcript

  • 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