Copyright ©2012 Ping Identity Corporation. All rights reserved.1
SAML, OAuth 2, and OpenID Connect
Overview
David WaitePing Identity Corporation
Copyright ©2012 Ping Identity Corporation. All rights reserved.
CLAIMS-BASED AND FEDERATED IDENTITY
2
Copyright ©2012 Ping Identity Corporation. All rights reserved.
Claims-based Identity
• Primarily a Microsoft-Pushed Concept–Unfortunate, less attention outside MS shops
• Trusted-party message w/ user attributes–Alternative to directory lookup off account name
• Authentication is an external concern–vs each mechanism implemented in each app
3
Copyright ©2012 Ping Identity Corporation. All rights reserved.
Claims-based Identity
• Could support multiple trusted issuers• Different levels of trust
–Can this issuer assert for this user?–Can this issuer assert the user has this role?
• A local trusted party may serve as intermediary/multiplexer–The Security Token Service (STS) Role
4
Copyright ©2012 Ping Identity Corporation. All rights reserved.
Claims-based Identity
• Policy decisions based on issuer, claims–vs group-based policy, local directory lookup–claims may map directly to policy decisions
• Local trusted issuer can centralize, push policy decisions in tokens
5
Copyright ©2012 Ping Identity Corporation. All rights reserved.
Federated Identity
• Making local decisions from remote trusted entities is distributed identity
• Since there is no global entity to trust, we call this “Federated Identity”
• In the consumer space, this is–Social Logins–Windows Live ID–OpenID systems
6
Copyright ©2012 Ping Identity Corporation. All rights reserved.
Web SSO vs API SSO
• Web Browser SSO–cross domain interactions–requires no browser extensions–query params or javascript form-post transport–form login, cookies for authentication
• API SSO–client logic to acquire tokens via authentication–cache/use tokens for API access
7
Copyright ©2012 Ping Identity Corporation. All rights reserved.
SECURITY ASSERTION MARKUP LANGUAGE (SAML)
8
Copyright ©2012 Ping Identity Corporation. All rights reserved.
SAML
• Security Assertion Markup Language–A.K.A, a format for Securely Asserting Identity Information
• Includes Web Single Sign-On (Web SSO)• Pieces leveraged by WS-Federation, WS-
Security, OAuth 2.0
9
Copyright ©2012 Ping Identity Corporation. All rights reserved.
Web SSO Problem
• How to talk about a user (entity)• Between multiple security domains• Where that entity has different identity
representations in each domain• Such that the entity can request resources• And not have to re-authenticate
10
Copyright ©2012 Ping Identity Corporation. All rights reserved.
SAML Details
• SAML is an XML format–With XML schema–Integrity, confidentiality protection via xmlsec–Almost always signed, encrypted with X.509–Often self-issued X.509 certs
• trust is established out-of-band
• Only a subset of features supported by majority of implementations
11
Copyright ©2012 Ping Identity Corporation. All rights reserved.
SAML Roles
• Identity Provider–Authenticates the user directly–Asserts identity to other services
• Service Provider–Requests, consumes identity to authenticate
the user
12
Copyright ©2012 Ping Identity Corporation. All rights reserved.
SAML Anatomy
• SAML Assertion–describes the entity
• SAML Protocol–request/response messages
• SAML Binding–how messages are sent
• SAML Profile–bindings and profiles used for a use case
13
Copyright ©2012 Ping Identity Corporation. All rights reserved.
SAML Anatomy
• Interesting Bits–SAML Assertion
• token used by other specs–SAML Web Browser SSO Profile
• describes how to send browsers cross domains to authenticate users
14
Copyright ©2012 Ping Identity Corporation. All rights reserved.
Subset of SAML in wide use
• Web Browser SSO• Assertions
–subject - unique identifier in system• email, DN, employee ID
–attributes• personalization items like first/last name• groups, other information for policy decisions
15
Copyright ©2012 Ping Identity Corporation. All rights reserved.
SAML Limitations
• XML digital signatures are difficult–to implement–to reason about
• Majority of implementations only handle Web SSO
• Most API usage is WS-Security (SOAP)–OAuth 2.0 profile is in draft
16
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAUTH 2.0
17
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAuth 2.0
• Provides Authorization for API access–3rd party makes API calls on user’s behalf–Without asking for/caching user password–User can revoke client access individually–Changing password doesn’t break access
18
Copyright ©2012 Ping Identity Corporation. All rights reserved.
Existing Problem to Solve*
19
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAuth 2.0 Fundamentals
• Four parties defined–The User–The Client application–A Protected Resource requiring authorization–An Authorization Service
20
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAuth 2.0 Fundamentals
• Access tokens–message to resource from AS about client
• what they are allowed to do• who they represent
–usually opaque to the client–validation of token is not part of core spec
• local crypto check, or remote call–Requires secure transport (TLS)
21
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAuth 2.0 fundamentals
• Scopes–Clients request scope of usage for token
• API-specific strings or URIs–AS logic determines what scopes you get
• internal policy• user consent
–Good for pre-computing broad policy decisions
22
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAuth 2.0 Fundamentals
• Access token validation is often cached• Access tokens expire
• Refresh token–given to client alongside access token–can be used to request new access token–usually what is revoked by user–only shared between client and AS
23
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAuth 2.0 Benefits
• Splits token acquisition from token usage
• AcquisitionPOST /authsvcAuthorization: Basic dXNlcm5hbWU6cGFzc3dvcmQKgrant_type=password&username=jdoe&password=A3ddj3
• Usage:Authorization: Bearer YWNjZXNzdGtuCg==
24
Copyright ©2012 Ping Identity Corporation. All rights reserved.
Grant Types
• A few interesting grant_types:–username / password user auth–browser-based authentication and consent
• returning temporary code to exchange for token• returning token directly to be consumed by code
–client authentication w/o user–SAML (separate draft spec)–JWT (to discuss later)
25
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAuth 2.0 Concerns
• OAuth 2 is not a protocol, but a framework• No profiles for interoperability
–No Mandatory to Implement grant types–AS extends return value
• Token–Token might not be opaque to client–Resource → AS Token Validation
• Client → Resource token usage is solid
26
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAuth 2.0 Concerns
• OAuth 1 had message signing –for integrity protection
• Protect integrity/confidentiality with TLS
27
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAuth 2.0 Concerns
• But, OAuth 1 signing was–Request only–Only for URLEncoded request (no XML, JSON)–No existing support, had to be implemented–Home-grown impls broke on API changes–X.509-based signing often unimplemented–Confidentiality still required TLS
• OAuth 2 has work toward MAC signing
28
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAuth 2.0 Concerns
• OAuth requires client registration–limits API usage to registered clients
• except some username/password deployments
• Does not protect from malicious or phishing clients–but would support user authentication
mechanisms which would support this
29
Copyright ©2012 Ping Identity Corporation. All rights reserved.
JSON WEB TOKEN (JWT)
30
Copyright ©2012 Ping Identity Corporation. All rights reserved.
JSON Web Token
• Abbreviated JWT, pronounced “Jot”• Standard token format
–containing JSON data–supporting integrity, confidentiality
• Overly broad/bad definition–“SAML Assertions in JSON instead of XML”
31
Copyright ©2012 Ping Identity Corporation. All rights reserved.
JWT Overview
• Fills in some missing pieces–What is a good OAuth access token format?–What “standard” attributes should I care about?
• subject• “issued at” time• “not before”, “expiry” to provide validity window• “issuer”, “audience”• unique token identifier
32
Copyright ©2012 Ping Identity Corporation. All rights reserved.
JWT Features
• “Issuer” allows you to support multiple Authorization Servers
• Allow resources to consume token directly –without talking to AS
• OAuth 2 grant proposed to exchange remote JWT for local access token–federation
33
Copyright ©2012 Ping Identity Corporation. All rights reserved.
JWT Format
• Format is simple–URL-safe Base64-encoded data chunks,
separated by dots• crypto object defining integrity/
confidentiality checks• data object with some reserved keys
–possibly encrypted• optionally, signature block
34
Copyright ©2012 Ping Identity Corporation. All rights reserved.
JWT Proposed usage
• Eventual token form for APIs to support–network optimization
• Alternative to SAML for API access from other domains
35
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OPENID CONNECT
36
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OAuth 2.0 Caveat
• Not an Authentication Protocol on its own–Do not treat OAuth access tokens as
• proof authentication was performed recently• proof the party giving you this token is the user• that this token is meant for your client
–Generally, do not treat the token as a message to a client about the user
37
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OpenID Connect
• Completely New Protocol• Extends AS with OpenID Provider Role• Adds Identity Token (id_token) for SSO
–JSON Web Token–Message to client about user
• Adds UserInfo endpoint• Adds hybrid flows
–client is split between local and hosted pieces
38
Copyright ©2012 Ping Identity Corporation. All rights reserved.
OpenID Connect
• Adds Dynamic Registration of clients• Adds Discovery of OpenID Provider
metadata on domain– via /.well-known/
39
Top Related