Openstack identity protocols unconference

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


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

• AcquisitionPOST /authsvcAuthorization: Basic dXNlcm5hbWU6cGFzc3dvcmQKgrant_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

Technology