Openstack identity protocols unconference

Copyright ©2012 Ping Identity Corporation. All rights reserved.1
SAML, OAuth 2,
and OpenID Connect
Overview
David Waite
Ping Identity Corporation

Copyright ©2012 Ping Identity Corporation. All rights reserved.
CLAIMS-BASED AND
FEDERATED IDENTITY
2

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

• 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

• 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

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

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

SECURITY ASSERTION MARKUP
LANGUAGE (SAML)
8

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

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

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

SAML Roles
• Identity Provider
–Authenticates the user directly
–Asserts identity to other services
• Service Provider
–Requests, consumes identity to authenticate
the user
12

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

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

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

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

OAUTH 2.0
17

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

Existing Problem to Solve*
19

OAuth 2.0 Fundamentals
• Four parties defined
–The User
–The Client application
–A Protected Resource requiring authorization
–An Authorization Service
20

• 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

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

• 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

OAuth 2.0 Benefits
• Splits token acquisition from token usage
• Acquisition
POST /authsvc
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQK
grant_type=password&username=jdoe&password=A3ddj3
• Usage:
Authorization: Bearer YWNjZXNzdGtuCg==
24

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

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

OAuth 2.0 Concerns
• OAuth 1 had message signing
–for integrity protection
• Protect integrity/confidentiality with TLS
27

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

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

JSON WEB TOKEN (JWT)
30

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

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

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

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

JWT Proposed usage
• Eventual token form for APIs to support
–network optimization
• Alternative to SAML for API access from
other domains
35

OPENID CONNECT
36

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

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

OpenID Connect
• Adds Dynamic Registration of clients
• Adds Discovery of OpenID Provider
metadata on domain
– via /.well-known/
39

Openstack identity protocols unconference

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Openstack identity protocols unconference

Similar to Openstack identity protocols unconference (20)

Recently uploaded

Recently uploaded (20)

Openstack identity protocols unconference