IdP Selection WG

A proposal to next steps(Draft)

Version v0.3.1

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.

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 ?).

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.

Pending point to be discussed: which strategy ?

• 3 possible models for an ISA in the network

a. The ISA as a facilitator : just allows the user to select the IDP and everything else is done directly between RP and IDP

b. The ISA as an IDP proxy, as defined in the Liberty/SAML specifications

c. the ISA acts on behalf of the SP and just convert flows from a protocol to an other if needed

ISA as a facilitator 1/2

Functional view

IDPISA

RP

Metadata exchange & IDP Selection Delegation

Some metadata only *

Metadata exchange & Authenticationdelegation

* e.g. for the IDP capabilities discovery

ISA as a facilitator 2/2

ISA

RelyingParty

IdentityProvider

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

Note : numbers to represent the order of the interactions.

Technical view

ISA is as an IDP proxy 1/2

Functional view

IDP ISA RP

Metadata exchange & IDP Selection & Authenticationdelegation

Metadata exchange & Authenticationdelegation.

RP IDP

ISA is as an IDP proxy 2/2

IdentityProvider

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

Userdatabase

ISA

RelyingParty

Note : depending on the protocol, links ,, and may or may not go through the browser.

Note : numbers to represent the order of the interactions.

Technical view

ISA acts on behalf of the SP 1/2

Functional view

IDPISA

RP

Metadata exchange & IDP Selection & Authentication delegation (acting on behalf of the real RP)

Authentication delegation

RP

Remote RP endpoints

metadata

ISA acts on behalf of the SP 2/2

ISA

IdentityProvider

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.

RelyingParty

Note : depending on the protocol, links ,, and may or may not go through the browser.

Note : numbers to represent the order of the interactions.

Technical view

Roadmap proposal

Mar

ch p

lenar

y

First d

raft

for "

Techn

ical

way to

inte

grat

e th

e IS

A"

First d

raft

for "

met

adat

a

spec

s evo

lution

"

GUI and

UX g

uideli

nes

ISA im

plem

enta

tion

guide

lines

July

Octob

er