1 / 12

IdP Selection WG

A proposal to next steps (Draft) Version v0.3.1. IdP Selection WG. Identified requirements. Input requirements identified in the IDP Selection MRD can be divided into 4 main categories :

myra
Télécharger la présentation

IdP Selection WG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A proposal to next steps (Draft) Version v0.3.1 IdP Selection WG

  2. Identified requirements • Input requirements identified in the IDP Selection MRD can be divided into 4 main categories : • Possibility for the SP to delegate the selection of the user's IDP to an ISA and express some criteria to be considered for that selection process. • Discovery of the user's preferred IDP(s) by ISAs. • Possibility for the ISA to obtain user's IDP(s) capabilities as well as other data (metadata). • GUI and UX guidelines for SP and ISA.

  3. Envisioned next step 1/2 • Delegate to the ISA • Extract from MRD all needed claims, both by IdP and by RP • Technical way to integrate the ISA on SP side using RP metadata (aim : same metadata for both ISA in the browser and in the network) • Discovery of the user's preferred IDP • Mainly internal to the ISA (to be assessed based on MRD) : should be described into an "ISA implementation guidelines" document (common guidelines for both ISA in the browser and in the network ?).

  4. Envisioned next step 2/2 • IDP's capabilities • Lacks in existing IdP metadata specifications already identified in the "Gap analysis" document : requires evolutions on these specifications. • E.g. • Supported authentication context by IDP • Logo and display name for each IDP • … • GUI and UX guidelines for SP and ISA. • Common guidelines for both ISA in the browser and in the network.

  5. Pending point to be discussed: which strategy ? • 3 possible models for an ISA in the network • The ISA as a facilitator : just allows the user to select the IDP and everything else is done directly between RP and IDP • The ISA as an IDP proxy, as defined in the Liberty/SAML specifications • the ISA acts on behalf of the SP and just convert flows from a protocol to an other if needed

  6. ISA as a facilitator1/2 • Functional view Some metadata only * Metadata exchange & IDP Selection Delegation IDP RP ISA Metadata exchange & Authentication delegation * e.g. for the IDP capabilities discovery

  7. ISA as a facilitator 2/2 • Technical view • ISA used only during the IDP choice • The ISA is not aware of the rest of the transaction • The RP must implement all protocols corresponding to the various IDP Identity Provider Relying Party ISA       Note : numbers  to  represent the order of the interactions.

  8. ISA is as an IDP proxy1/2 • Functionalview Metadata exchange & Authentication delegation. Metadata exchange & IDP Selection & Authentication delegation IDP ISA RP RP IDP

  9. ISA is as an IDP proxy 2/2 • Technical view User database • Protocol on link  and  can be any widely spread protocol. • As a proxy, the ISA must implement fully the chosen protocol(s) for links  and . • Possibly single protocol between ISA and RP • IDP doesn't have knowledge of the RP and vice versa. • In case of ISA failure, users can't access the RP anymore (or with complex failover mecanism) • Users must exist in the ISA database (needs provisioning) • Might be a problem for the RP to access to IDP APIs Identity Provider Relying Party ISA       Note : numbers  to  represent the order of the interactions. Note : depending on the protocol, links ,, and  may or may not go through the browser.

  10. ISA acts on behalf of the SP1/2 • Functionalview Metadata exchange & IDP Selection & Authentication delegation (acting on behalf of the real RP) Authentication delegation IDP RP ISA RP metadata Remote RP endpoints

  11. ISA acts on behalf of the SP 2/2 • Technical view • Protocol on links  and  can be any widely spread protocol. • As an intermediary, the ISA must implement fully the chosen protocol(s) for links  and . • Single protocol between ISA and RP • Opportunity to specify a simplified SSO profile of existing specs for steps  and  • In case of ISA failure, SP can use another one or no ISA. Identity Provider Relying Party ISA       Note : numbers  to  represent the order of the interactions. Note : depending on the protocol, links ,, and  may or may not go through the browser.

  12. Roadmap proposal March plenary October July First draft for "metadataspecs evolution" First draft for "Technicalway to integrate the ISA" GUI and UX guidelines ISA implementationguidelines

More Related