Planned Interop Scenarios for RSA 2009

Proxying Assurance Between OpenID and SAML

Use Case: SAML then OpenID (submitted by NTT)

Description

This use case has a SAML IdP providing strong authentication to its constituency of RPs. The IDP wants to focus exclusively on strong authentication methods, but the SAML RPs do still have the need for lower end password authentication in addition to stronger mechs. Consequently, the SAML IdP wants to outsource such pwd authentication to OPs (possibly whitelisted) through OpenID.
If and when a SAML RP sends an authentication request to the IDP specifying strong authentication using SAML authentication context, the IDP will deal with the request itself. But, should the RP ask for a password authentication, the SAML IdP will proxy that request to an OP (now acting as an OpenID RP), using PAPE to stipulate an appropriate authentication policy. Once the user is authenticated by the OP and sends the OpenID response back to the requesting RP, that entity will again flip roles and, acting as a SAML IDP, send the appropriate SAML response message to the original SP.

Actors

samlsp.example.com - the SAML SP that requests authentication of the SAML IDP
Requires SAML Web SSO profile SP support
proxy.example.com - the entity that acts as a SAML IDP to the SAML Service Provider samlsp.example.com, but as an OpenID RP to the OpenID Provider openidop.example.com
Requires SAML Web SSO profile IDP & OpenID RP support
openidop.example.com - the OpenID Provider that authenticates the User with a low assurance password authentication when requested to by the proxy proxy.example.com
Requires OpenID OP support

Preconditions

User has accounts at samlsp.example.com, proxy.example.com, and openid.example.com
Accounts between samlsp.example.com and proxy.example.com have been linked
User credential at openid.example.com is a password
User credential at proxy.example.com is 'stronger' (TBD, self-issued card?)

Sequence

There are two variants, depending on whether samlsp.example.com stipulates a password authentication context in its request to proxy.example.com, or a 'stronger' authentication context. For the former, the request will be proxied to the OP, for the latter, it will be processed locally.
The SAML SP and IDP must be able to support both variants, the OpenID only the first.

Variant 1 Password authn

1) User accesses low value resource at samlsp.example.com
2) samlsp.example.com composes <saml:AuthnRequest> and sends to proxy.example.com
Binding TBD
AuthnRequest uses the <saml:RequestedAuthnContextClass> to stipulate the SAML 2.0 password authentication context class
3) proxy.example.com determines that the request from samlsp.example.com should be proxied to an OP
proxy.example.com maps the <saml:AuthnRequest> into a corresponding OpenID request.
proxy.example.com uses OpenID PAPE to stipulate to the OP that it desires a password authentication
We'll need to spin up a password PAPE URI (TBD)
4) proxy.example.com discovers OP (how out of scope) and sends OpenID request to openid.example.com
5) openid.example.com interprets PAPE policy and prompts user for password authentication
6) Assuming successful login, openid.example.com uses PAPE to express that the user was authenticated with password, and returns user to proxy.example.com with OpenID response
7) proxy.example.com verifies OpenID response and maps to a <saml:Response> and delivers back to samlsp.example.com
Binding TBD
AuthenticationCOntext stipulates the SAML 2.0 password authentication context class
AuthenticatingAuthority specifies the OP
8) samlsp.example.com verifies the <saml:Response> and grants access to User to requested low-value resource.
samlsp.example.com UI should indicate that the authentication was performed by the OP and that it was password based

Variant 2 - Stronger Authn

1) User accesses high value resource at samlsp.example.com
2) samlsp.example.com composes <saml:AuthnRequest> and sends to proxy.example.com
Binding TBD
AuthnRequest uses the <saml:RequestedAuthnContextClass> to stipulate a 'stronger' SAML 2.0 authentication context class
Specific class: TBD
3) proxy.example.com determines that the request from samlsp.example.com should be handled locally
proxy.example.com prompts user for strong authentication
4) Assuming successful login, proxy.example.com composes <saml:Response> and delivers back to samlsp.example.com
Binding TBD
AuthenticationCOntext stipulates the chosen SAML 2.0 stronger authentication context class
AuthenticatingAuthority empty
4) samlsp.example.com verifies the <saml:Response> and grants access to User to requested high-value resource.
samlsp.example.com UI should indicate that the authentication was performed by the SAML IDP and that it was 'strong' (specific mech TBD)

Use Case: OpenID then SAML (submitted by NRI)

Description

This use case has an OpenID provider bootstrapping PAPE requests of OpenID relying parties to Authentication Context requests for a SAML IDP providing high assurance authentication to its constituency of RPs. The OP wants to focus exclusively on low assurance authentication; however, the OP still receives all OpenID authentication requests including high assurance ones and forwards them to a proper SAML IDP that gurantees the levels and the policies required by RPs. In this use case, RPs do not have to support SAML RP capability and the OP acts as a "Proxy" to the SAML IDP for the RPs. A pre-agreement among the OpenID RPs, the OP, and the SAML IDP must be set in order to put them in the same authentication/assurance context and to define each roles.
If and when a OpenID RP sends an authentication request to the OP without specifying authentication policies and an assurance level in a OpenID PAPE request message, the OP will deal with the request itself by verifying User's ID and Password and return a PAPE response message immediately back to the RP with no policy and no assurance level. If the OP receives an authentication request specific authenticaton policies (e.g. Multi-Factor Authentication) and an assurance level and it determines not to handle the request by itself, the OP composes a SAML request with Authentication Context and redirects an User to the SAML IDP for strong authentication instead. Once the SAML IDP successfully authenticates the User with a strong authentication method, it redirects the User back to the OP with a SAML assertion. Finally, the OP creates a PAPE response message out of information in the SAML assertion and redirect the User back to the RP with the message.

Actors

openidrp.example.com
The OpenID Relying Party(the RP) that is a service provider such as an e-commerce site.
It requires OpenID Providers high assurance authentication for manetaty-valued transactions with Users.
It requires OpenID RP support.
openidop.example.com
The OpenID Provider(the OP) that authenticates the User with password authentication for low assurance request from an OpenID RP.
It forwards(redirects) the User to the SAML IDP when the RP requests high assurance (e.g. two factors authN and identity proofing) authentication.
It requires both OpenID OP and SAML RP support.
samlidp.example.com
The SAML IDP that manages Users' credentials for high assurance authentication and authenticates Users sent from SAML RPs.
It requires SAML IDP support and connectibity to an external strong authenticaton service such as one-time password.

Preconditions

User has an account at each of openidop.example.com and samlidp.example.com.
Accounts between openidop.example.com and samlidp.example.com have been mapped.
User credential at openidop.example.com is a password.
User credential at samlidp.example.com is 'stronger' (e.g. one-time password tied with User's cell phone).
Proper trust relationship (e.g. Circle of Trust) between openidop.example.com and samlidp.example.com is established.
Proper conditions such as assurance programs must be set for openidrp.example.com to trust openidop.example.com behalf of samlidp.example.com.
The Firewall sitting in front of samlidp.example.com allows asscess from the User's agent.

Sequence

User accesses high value resource at openidrp.example.com.
openidrp.example.com composes a OpenID AuthN request message with PAPE parameters(e.g. opendi.pape.preferred_auth_policies=http://schemas.openid.net/pape/policies/2007/06/multi-factor and openid.pape.auth_level.ns.jisa=http://www.jisa.or.jp/spec/auth_level.html) and redirect the User to openidop.example.com with the message.
openidop.example.com looks at those PAPE parameters and determines if it can handle the request. If not, it composes <saml:AuthnRequest> with a corresponding <saml:RequestAuthnContextClass> to the PAPE request and redirects the User to samlidp.example.com for a proper authentication process.
samlidp.example.com instructs the User for strong authentication that matches with the policies and assurance level specified in the PAPE parameters.
If the authentication successes, samlidp.example.com composes <saml:Response> and redirect the User back to openidop.example.com with the SAML assertion.
openidop.example.com verifies the SAML assertion. If the verification successes, it composes a OpenID response message with PAPE parameters(e.g. openid.pape.auth_policies=http://schemas.openid.net/pape/policies/2007/06/multi-factor and openid.pape.auth_level.jisa=2) and redirect the User back to openidrp.example.com with the message.
openidrp.example.com verifies the OpenID response message and the PAPE parameters. If the verification successes, its UI should indicate that the authentication was performed along with the policy and grants the User to access high value resource.

Bootstrapping from SAML to OAuth?

(...)

Authentication-method discovery enabling identity-enhanced browsers

Description

This scenario is driven by these observations:
There are now many methods for browser authentication to web applications, and it is likely that no one method will displace all the others. Popular methods include OpenID, SAML, I-card, Kerberos, X.509 certificates, and of course POUP (Plain Old Username and Password aka HTTP+HTML Form based authentication). Each has its own approach to invocation and user interaction. This is a mess for users and for site developers.
Adding support in the browser (via plugins/addons or natively) for authentication can significantly improve both usability and security. I-cards are based on the notion of in-browser support. Add-ons supporting other methods such as OpenID demonstrate these benefits. Supporting multiple protocols via add-ons across multiple popular browsers (IE, Firefox, Safari, Chrome, etc) on multiple OSes is daunting. Promoting a common approach to this support is appealing.
There is much current interest in publishing and discovery of site/service metadata for various purposes including authentication. Again discovery tends to be per-protocol. Many groups are looking at XRD (new work based on XRDS and XRDS-Simple) as a unifying approach for discovery.
The scenario is multi-protocol browser add-ons for identity using published site metadata via XRD for authentication support to deliver an improved signon experience for users and site developers. Both SP/RP and IdP sites can support discovery via metadata.

Actors

Relying party and identity-provider sites signon-enabled with one or more of OpenID, I-card, and SAML.
Browsers signon-enabled with add-ons supporting one or more of OpenID, I-card, and SAML.

Preconditions

User accounts on RPs and IdPs.
RPs and IdPs publish site authentication method support in metadata in discoverable location.
Browser add-ons configured with user's preferred methods and IdPs (cards, in the I-card case).

Sequence

User browses to unprotected page on RP and initiates signon.
Browser add-on finds and fetches RP site metadata and uses it to discover authentication method support.
This triggers appropriate browser or add-on UI to engage user for signon, possibly involving IdP interaction.
(...)