DIWD Concordia

2,205 views

Published on

Project Concordia presentation by Patrick Harding, Paul Madsen, and Mary Ruddy at DIDW 2008

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,205
On SlideShare
0
From Embeds
0
Number of Embeds
155
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • DIWD Concordia

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

    ×