CIS13: Federation Protocol Cross-Section

1
Copyright ©2013 Ping Identity Corporation. All rights reserved.
Federation Protocols:
A Cross-Section
David Waite
Technical Architect, Ping Labs
1

2
Who am I?
• David Waite
• In Identity Space for 10 years
• With Ping Labs group
Mad Scientist and Mad Science Facilitator

3
Alternative Talk Name #1
Build your own Federated Identity Protocol

4
Rejected!
• Do not want to encourage people to build
their own protocols!
• Confusing with other aspects of talk

5
Alternative Talk Name #2
SAML 101: The Speed Run

6
Rejected!
• But, not just going to on just one protocol
– SAML 2.0
– WS-Federation
– OpenID Connect
– and friends
• all at once

7
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
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
Basics of Federated Identity
9

10
The Venerable Login Form

11
(Local) Login Process
• Detect need to authenticate user
• Authentication Request(Challenge)
• Receive Response
• Validate Response
• Success!

12
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
Local Login Process (Redux)
• Authentication Request (Challenge)
• Receive Response
• Validate Response
• Success!

14
SAML SP Login Process
• Send AuthnRequest
• Receive AuthnResponse
• Validate AuthnResponse
• Success!

15
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
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
Protocol Differences
17

18
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
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
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
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
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
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
OpenID Connect

25
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
Protocol Specifics
26

27
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
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
Response Commonalities
• User attributes and authentication
information
• Sent to Service Provider, verifiable via
– Front channel signed message
– Back channel (SAML and OpenID 2)

30
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
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
Final Detour: Discovery
32

33
Discovery
What if you had more than one way to log
in locally?

34
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
IDP Discovery
• No perfect strategy!
• Eventually, you have to either
– ask user to pick from list
– fail with user instructions

36
Option #1
User picks from list of all options

37
Option #1
• What about when you have too many
options?
• Identity providers may be your customers
• can you publicize your customer list?

38
Option 2
• OpenID - ask your user who they are first

39
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
Option 3
• Cardspace had an Active Component
– Knew where you could log in
– Services specified their needs for an IDP

41
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
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
Account Chooser
https://www.accountchooser.com/

44
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

CIS13: Federation Protocol Cross-Section

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to CIS13: Federation Protocol Cross-Section

Similar to CIS13: Federation Protocol Cross-Section (20)

More from CloudIDSummit

More from CloudIDSummit (20)

Recently uploaded

Recently uploaded (20)

CIS13: Federation Protocol Cross-Section