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


Who am I?

• David Waite •  In Identity Space for 10 years

• With Ping Labs group “Mad Scientist and Mad Science Facilitator”


Alternative Talk Name #1

Build your own Federated Identity Protocol


Rejected!

• Do not want to encourage people to build their own protocols!

• Confusing with other aspects of talk


Alternative Talk Name #2

SAML 101: The Speed Run


Rejected!

• But, not just going to on just one protocol

– SAML 2.0 – WS-Federation – OpenID Connect – and friends

• all at once


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


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


Basics of Federated Identity

9


The Venerable Login Form


(Local) Login Process

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


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


Local Login Process (Redux)

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


SAML SP Login Process

• Detect need to authenticate user • Send AuthnRequest • Receive AuthnResponse • Validate AuthnResponse • Success!


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


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


Protocol Differences

17


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


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


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


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


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


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


OpenID Connect


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”


Protocol Specifics

26


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


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


Response Commonalities

• User attributes and authentication information

• Sent to Service Provider, verifiable via – Front channel signed message – Back channel (SAML and OpenID 2)


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


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)


Final Detour: Discovery

32


Discovery

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


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?


IDP Discovery

• No perfect strategy!

• Eventually, you have to either – ask user to pick from list – fail with user instructions


Option #1

User picks from list of all options


Option #1

• What about when you have too many options?

•  Identity providers may be your customers • can you publicize your customer list?


Option 2

• OpenID - ask your user who they are first


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


Option 3

• Cardspace had an Active Component – Knew where you could log in – Services specified their needs for an IDP


Option 3

• Requiring active component to work limits adoption

• Users still had to ‘add’ Identity Providers – But their employer could do this for them


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


Account Chooser

https://www.accountchooser.com/


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

Technology

ping identity corporation

identity space

identity provider idp

federated identity protocol

federated identity thinking

basics of federated

client identity provider

web sso web sso share