1projectconcordia.org
Bootstrapping the Identity Metasystem
Mary Ruddy (Meristic), Patrick Harding (Ping ID) & Paul
Madsen (NTT)
2projectconcordia.org
Agenda
Bootstrapping? Project Concordia A Matrix of possibilities SAML-> OpenID (Paul) Infocards->ID-WSF (Mary) SAML->OAuth (Patrick) References Discussion
3projectconcordia.org
Bootstrapping
We enjoy/confront a number of different 'standards' for federated identity protocols/systems, e.g. SAML, OpenID, Oauth, Infocards, ID-WSF, WS-Federation,
Such heterogeneity is both a boon and a bane, while it gives deployers freedom to choose, it creates interoperability challenges across the systems
More and more, the protocols are expected to be deployed in combination (but they weren't necessarily designed with this expectation)
Bootstrapping refers to mechanisms that, when two or more protocols are chained together, enable the transition(s) between them
4projectconcordia.org
Project Concordia
“Agreement, understanding, and marital harmony”... Public forum driving interop among identity protocols
Used together in practice but not originally designed to fit together
Practical focus on real-life issues Gathering deployer input is an explicit goal
No technology is off-limits PKI, SAML, WS-Fed, OpenID, InfoCard, ID-WSF ...
Scenarios are explored, tested, and clarified in turn If further specification work is needed, Concordia may
champion its standardization in the appropriate forum
5projectconcordia.org
The Matrix
Frontchannel attributes
Backchannel attributes
Authn
SSO
SLO
OpenID SAML Infocards WS-Fed ID-WSF OAuth
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Paul
Mary
Patrick
6projectconcordia.org
SAML ->OpenID
7projectconcordia.org
SAML->OpenID
Both SAML & OpenID define mechanisms to support statements such as I require the user to be authenticated with a password The user was authenticated at Level Of Assurance 'Gold'
SAML defines Authentication Context, OpenID the Provider Authentication Policy Extension (PAPE)
Both effectively ride on top of the core SSO protocol, giving RP & IDP enhanced ability to express such policies
AC & PAPE are logically equivalent, differ in syntax
8projectconcordia.org
SAML Authentication Context
SAML Authentication allows IDP/SP to indicate policy on SSO messages wrt Identity proofing (e.g. Email verification or f2f) Security processes (e.g. Key storage) Authentication specifics (e.g. Biometric or OTP) Assurance levels (work under way)
Authentication Context 'classes' capture common combinations of above aspects - SSTC defined a number, e.g. 'mobile-nocontract'
New classes can be defined by other some communities (not without some difficulty)
9projectconcordia.org
OpenID PAPE
OpenID Provider Authentication Policy Extension PAPE is a (relatively) simple mechanism PAPE standardizes 3 URIs
Multi-factor Multi-factor Hard token Phishing Resistant
Also allows providers to indicate assurance in terms of NIST 800 63 levels
10projectconcordia.org
Motivating Use Case
A SAML IDP provides strong authentication services to a community of RPs IDP focuses on strong authentication, and outsources low assurance
requests to OPs through OpenID Value
For SAML RPs, leveraging their existing IDP relationship to mediate those with OPs
For OpenID OPs, (indirect) access to those erstwhile exclusively SAML RPs
If and when a SAML RP uses saml:AuthnContext to ask for a low assurance authentication, SAML IDP will proxy that request to the user specified OP – with openid:PAPE
Implies that SAML AC class URIs & PAPE URIs must be mapped
OpenID
SAML
SAMLrequestedauthncontext(password)
authncontext(password)
pape(password)
RP IdP/RP OP
pape(password)
logon(pwd)
service?
service
1
2
3
4
Sequence
12projectconcordia.org
<Ointment><Fly/><Fly/></Ointment>
PAPE does not define a password URI SAML does not (yet) define how to bind the NIST
800 63 assurance levels to Authn Context Can we presume that the two protocols are
equivalent with respect to LoA? PAPE gives non-normative guidance on how
typical authentication mechanisms (some overlap with SAML's classes) map into the PAPE URIs
13projectconcordia.org
Information Cards -> ID-WSF
14projectconcordia.org
Infocards->ID-WSF
Overview of protocols Motivation for use case Approach
15projectconcordia.org
ID-WSF
Identity Web Services Framework Developed by Liberty Alliance Framework to support Federated Web Services Specification released in 2003 Supports circles of trust “Back Channel Identify”
16projectconcordia.org
Today you go from site to site filling in forms and
passwords
Copyright © 2008 Parity. Made available under EPL 1.0 16
Type, type, type. Click, click. Here a password, there a password. Everywhere a password.Here a form, there a form, ...
Websites…
17projectconcordia.org
Information Cards Put You in Control
Copyright © 2008 Parity. Made available under EPL 1.0 17
Each card is a slice of the digital you (or a friend of yours) held in some data silo.
Any kind of information:your preferences, favorite songs, employee id numbers, drivers licenses, affiliations, your health plan id, ...you get the idea, can be accessed using a card.
This wallet-like thing is an app called an Identity Selector
18projectconcordia.org
19projectconcordia.org
Sample Use Case
20projectconcordia.org
The information card ID-WSF bootstrap
The opportunity: Information Cards can be handy human consumable
ID-WSF Containers (representing Discovery Service Endpoint References [DS-EPRs] EPRs and relationships such as subscriptions)
Or from the other perspective, the DS provides a web services interface to the information card service
21projectconcordia.org
Bootstrap Flow
Identity Selector
Browser Extension & Client App
Identity Provider
Relying Party Website or App
Cards are generated and downloaded from here. Token Service issues tokens as requested by Selector.
Cards are stored and selected here
Tokens containing claim data are requested and received here ( tag on Website contains a reference for an ID-WSF service)
22projectconcordia.org
ID-WSF integration- Higgins IdP
Identity Selector
IdAS
LDAP Server
ID-WSF
Layer
ID-WSF Personal Profile Service
ID-WSF CP
LDAPCP
PP CP
I-card Services
DS ISASID-WSFSTS
23projectconcordia.org
SAML -> OAuth
24projectconcordia.org
SSO + Data
SAML handles federated browser SSO Secure Internet SSO Attribute Sharing Account Linking between different sites
OAuth handles delegated web service authentication secure API authentication Secure access to web service data API’s Generally with explicit user consent
25projectconcordia.org
Sample Use Case
Online Brokerage partners with third party Calculators site
Online Brokerage requires Calculators site to implement SSO via SAML Automated upload of account balances and holdings via API
Online Brokerage requires user consent and user presence before releasing user account balances to Calculators Site
Similar Use Cases Benefits Provider partners with Wellness Site Cable Operator partners with Gaming Site
26projectconcordia.org
SP-Initiated SAML
Brokerage.com
Identity Provider
Brokerage.com
Identity Provider
Calculators.com
Service Provider
Calculators.com
Service Provider
BrowserBrowser
1. SAML MetaData Exchange(i.e. Certs/Keys, EndPoints)
5. User redirect backwith SAML Token
4. UserAuthenticates &Handles User Consent
3.User redirect withSAML AuthN Request
6. Get Account Balances with SAML Token
2. ViewCalculators 7. Display
Calculators
APIAPI
27projectconcordia.org
Step 6
Leveraging SAML SSO Token for Web Service Requests SAML SSO Token not profiled for delegated web service
authentication Violates multiple SAML processing rules
TTL’s, AudienceRestrictions, SubjectConfirmation, InResponseTo IdP must ignore the SAML Token validation failures Not profiled for interoperability between Federation products and
Web Service Security tools Limited utility
’
28projectconcordia.org
OAuth
Brokerage.com
OauthService Provider
Brokerage.com
OauthService Provider
Calculators.com
OAuth Consumer
Calculators.com
OAuth Consumer
BrowserBrowser
1. Consumer Key and Secret
6. User Redirect back with Authorized Request Token
5. UserAuthenticates &Handles User Consent
4. User Redirect with Unauthorized Request Token
8. Get Account Balances with Access Token
2. View Calculators
3. Get Unauthorized Request Token
7. Exchange Authorized Token for AccessToken APIAPI
10. Display Calculators
29projectconcordia.org
Bootstrapping Possibilities
Leverages existing SAML partner PKI certificates for oAuth RSA signatures Eliminate consumer key and secret used for HMAC signatures
Leverage SAML messages to carry oAuth Request Tokens Eliminates second round of oAuth browser redirects SAML Request includes oAuth Unauthorized Request Token SAML Response includes oAuth Authorized Request Token
Can also works for IdP initiated SAML SSO Alternate SAML bindings such as Artifact
30projectconcordia.org
SAML + oAuth
Brokerage.com
Identity Provider
Brokerage.com
Identity Provider
Calculators.com
Service Provider
Calculators.com
Service Provider
BrowserBrowser
1. SAML MetaData Exchange(i.e. Certs/Keys, EndPoints)
5. User redirect backwith SAML Token + oAuth Authorised Token
4. UserAuthenticates &Handles User Consent
3.User redirect withSAML AuthN Request + oAuth Unauthorized Token
2. ViewCalculators 8. Display
Calculators
APIAPI
7. Get Account Balances with Access Token
6. Exchange Authorized Token for AccessToken
31projectconcordia.org
Optimization
Reduce operational complexity Simplify monitoring/troubleshooting
Improve User Performance & Latency Eliminate extra browser redirects
Leverage existing capabilities and infrastructure given SAML important without oAuth
IdP requires vanilla SAML SSO with other partners OAuth important without SAML
SP requests data from other oAuth enabled sites
32projectconcordia.org
Questions?
Top Related