Draft of a Deployment Guide for Proxying Assurance between OpenID & OAuth
Hi, as discussed at Vegas, NRI & NTT have been working on the enclosed, essentially writing down the lessons learned about proxying between SAML AC & OpenID PAPE in the RSA IOP demo We're hoping for initial discussion within the Concordia DG, with a decision as to next steps (e.g. perhaps spin up a new WG in order to publish as a KI Recommendation...) to come. Feedback welcome Paul -- Paul Madsen e:paulmadsen @ ntt-at.com m:613-282-8647 web:connectid.blogspot.com ConnectID <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
Teeny correction to make in above subject line s/OAuth/SAML/g Paul Madsen wrote:
Hi, as discussed at Vegas, NRI & NTT have been working on the enclosed, essentially writing down the lessons learned about proxying between SAML AC & OpenID PAPE in the RSA IOP demo
We're hoping for initial discussion within the Concordia DG, with a decision as to next steps (e.g. perhaps spin up a new WG in order to publish as a KI Recommendation...) to come.
Feedback welcome
Paul -- Paul Madsen e:paulmadsen @ ntt-at.com m:613-282-8647 web:connectid.blogspot.com ConnectID <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
------------------------------------------------------------------------
TOC <#toc>
Draft P. Madsen NTT T. Sakushima NRI October 6, 2009
Deployment Guide for Proxying Assurance between OpenID and SAML
Abstract
SAML and OpenID are key federated identity protocols. Both SAML and OpenID define mechanisms in support of expressing assurance information on protocol messages, respectively Authentication Context and the Provider Authentication POlicy Extension (PAPE). In deployment scenarios that require proxying from one of the protocols to the other, it becomes necessary to map to and from the corresponding assurance mechanisms. This document provides guidance on this mapping and related issues.
------------------------------------------------------------------------
Table of Contents
1. <#anchor1> Requirements notation 2. <#anchor2> Overview 2.1. <#anchor3> SAML Authentication Context 2.2. <#anchor4> OpenID PAPE 3. <#anchor5> Motivation 4. <#anchor6> Proxying 4.1. <#anchor7> User visits OpenID RP 4.1.1. <#anchor8> Request 4.1.2. <#anchor9> Response 4.2. <#anchor10> User visits SAML SP 4.2.1. <#anchor11> Request 4.2.2. <#anchor12> Response 5. <#anchor13> Future Considerations 6. <#anchor14> Security Considerations 7. <#rfc.references1> References § <#rfc.authors> Authors' Addresses
------------------------------------------------------------------------ TOC <#toc>
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
------------------------------------------------------------------------ TOC <#toc>
2. Overview
In the context of federated identity protocols, assurance refers to the degree of confidence a Relying Party (RP) can ascribe to the identity assertions an Identity Provider (IdP) makes regarding end-users. In the absence of legal contracts indemnifying the RP from any risk involved in accepting such assertions, an RP's confidence (and consequent willingness to accept the assertions) may be increased through knowledge of the policies & processes followed by the IdP in issuing the assertion. For instance, in a Single Sign On application, the degree of confidence the RP has in the assertion from the IdP as to the authentication status of the User may depend on a number of factors, including how the User was originally registered at the IDP, and how they were subsequently authenticated.
Notwithstanding that assurance is ultimately a continuum, it is typically categorized into levels (LOA) for practicality. Assurance frameworks (such as NIST 800 63) stipulate the required policies and procedures that an IdP must perform in order to meet defined LOA.
Both SAML & OpenID define mechanisms in support of expressing assurance information on protocol messages, respectively Authentication Context and the Provider Authentication Policy Extension (PAPE). Through these mechanisms, an RP is able to express its assurance expectations on its request message to the IdP for authentication, and the IdP is able to express the actual assurance achieved on its response message back.
In deployment scenarios that require proxying from one of the protocols to the other, it may become necessary for the proxying entity to map between the SAML and OpenID assurance mechanisms. While similar, the two mechanisms make different assumptions about expressing assurance - thereby creating the possibility of issues for the proxy. This document provides guidance to those entities playing the role of proxy on this mapping and related issues.
------------------------------------------------------------------------ TOC <#toc>
2.1. SAML Authentication Context
SAML Authentication Context [SAMLAC] (Kemp, J., "SAML Authentication Context," March 2005.) <#SAMLAC> provides a number of related mechanisms by which the SAML IDP & SP can indicate the nature of authentication, registration, proofing etc and thereby facilitate the RP establishing an appropriate level of assurance in the IDP's assertions. Authentication context is defined as the information, additional to the authentication assertion itself, that the relying party may require before it makes an entitlements decision with respect to an authentication assertion.
SAML defines authentication context classes to facilitate SPs making assurance decisions. Each class defines a proper subset of the full set of authentication contexts. Classes have been chosen as representative of the current practices and technologies for registration and authentication technologies.
------------------------------------------------------------------------ TOC <#toc>
2.2. OpenID PAPE
The OpenID Provider Authentication Policy Extension (PAPE) [PAPE] (Recordon, D., "Provider Authentication Policy Extension," March 2008.) <#PAPE> allows the RP and OP to discuss the specifics of how the user authenticated to the OP. Through PAPE, an OpenID RP is able to add to the OpenID Authentication request additional authentication requirements, specifically stipulating its preference for how the user was authenticated, and specify how long ago that authentication is allowed to have occurred.
PAPE defines 3 URIs for what are expected to be relevant authentication mechanisms.
http://schemas.openid.net/pape/policies/2007/06/phishing-resistant - An authentication mechanism where the End User does not provide a shared secret to a party potentially under the control of the Relying Party.
http://schemas.openid.net/pape/policies/2007/06/multi-factor - an authentication mechanism where the End User authenticates to the OpenID Provider by providing over one authentication factor.
http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical - An authentication mechanism where the End User authenticates to the OpenID Provider by providing over one authentication factor where at least one of the factors is a physical factor such as a hardware device or biometric.
In addition to specifying particular authentication technologies or characteristics as above, PAPE also supports more abstract LOA. It is worth noting that, while PAPE allows an OP to make a claim for a LOA on its response, PAPE does not allow the requesting RP to indicate a desired LOA on its request (although a desired LOA could be placed within the PAPE authentication policy param on the request).
------------------------------------------------------------------------ TOC <#toc>
3. Motivation
For SSO, both SAML and OpenID depend on an interaction between a RP and an IdP - the RP requests of the IdP that a visiting User be authenticated and the fact and nature of this authentication be returned to the RP. Neither SAML nor OpenID require that the IdP actually itself perform the authentication - in principle allowing the IdP to outsource the job just like the RP did.
Consequently, it is possible for an authentication request sent from an OpenID RP to an OpenID Provider (OP) to be proxied by that OP using SAML to a SAML IdP for the actual authentication of the User through presentation of a credential. This might be the case if the original OpenID RP were to request a higher LOA than could be satisfied by the OP which, in order to satisfy the request, would proxy the request through SAML to a SAML IdP that could satisfy the desired LOA.
Likewise, it is possible for an authentication request sent from a SAML SP to an SAML IDP to be proxied by that IdP using OpenID to a OP for the actual authentication of the User. This might be the case if the original SAML SP were to request a lower LOA than than supported by the SAML IdP which, in order to satisfy the request, would proxy the request through OpenID to an OP that could satisfy the desired LOA.
------------------------------------------------------------------------ TOC <#toc>
4. Proxying
Below are recommendations for the entity playing the role of protocol proxy between SAML & OpenID, differentiated by the protocol supported by the eventual consumer of the assertion.
------------------------------------------------------------------------ TOC <#toc>
4.1. User visits OpenID RP
This scenario has the user visit an OpenID RP first. The authentication at the chosen OP is proxied through SAML to an appropriate IdP. This scenario is shown below:
+----+ +----+ +--------+ +--------+ | UA | | RP | | OP/SP | | IdP | +-+--+ +-+--+ +---+----+ +---+----+ | | | | | | | | +<- - - - - - - - | | | . | | | | +-----------------+--- PAPE ------>| | | | | | +<- - - - - - - - - - - - - - - - -| SAML | . | | | | +-----------------+-- AuthnCont -------------------->| | | | | <- - - - - - - - - - - - - - - - - - - - - - - - - -| | | | | -----------------+---- Log in -------------------->| | | | | +<- - - - - - - - - - AuthnCont - - - - - - - - - - -| . | | | | +-----------------+--------------->| | | | | | +<- - - - - - - - - - PAPE - - - -| | . | | | | +---------------->| | |
------------------------------------------------------------------------ TOC <#toc>
4.1.1. Request
If the OpenID authentication request contains a PAPE policy URI that the OP is unable to satisfy, the OP MAY choose to proxy the request through SAML to an IdP that can.
If the OpenID authentication request has openid.mode = "checkid_immediate", the OP MUST specify ForceAuthn = "false" and isPassive = "true" on any proxied SAML Authentication request.
If proxying, the OP SHOULD give the User the ability to choose the SAML IdP to be used. The OP SHOULD offer as choices only those IdPs that are known to satisfy the desired assurance requirements.
Once the user has selected an IdP, the OP SHOULD attempt to remember this preference for future use.
In composing a SAML AuthnRequest message to the chosen IdP, the OP should take the PAPE policy URI from the OpenID request and map into an appropriate SAML <RequestedAuthnContext><AuthnContextClassRef> value.
If the original OpenID request specified one of the PAPE defined authentication policies (e.g. phishing-resisistant), the OP MAY map this policy into an appropriate SAML-defined Authentication Context class URI (e.g. OTP) as the value of the <RequestedAuthnContext>. Alternatively, the OP MAY map the requested PAPE authentication policy into an appropriate LOA Authentication context class.
Either way, the OP MUST ensure that the specific authentication class or the general LOA requested of the SAML IdP provides equal or greater assurance than specified on the original OpenID request.
------------------------------------------------------------------------ TOC <#toc>
4.1.2. Response
Upon receiving the SAML <Response> message from the IdP, the OP SHOULD proxy the SAML message back to the original requesting RP using OpenID. The message MUST be constructed as an OpenID response to the original OpenID request.
If the SAML Response contains a <ProxyRestriction> element with a Count of zero, the IdP MUST NOT proxy the Response message to the OpenID RP. Instead, the OP SHOULD send a negative assertion with openid.mode = "cancel".
If proxying, the OP SHOULD attempt to map any SAML Authentication Context class identifiers from the SAML message into correponding PAPE identifiers on the OpenID response message to the RP.
If the SAML response message specified one of the SAML-defined Authentication Context class URI (e.g. OTP), the OP MAY map this policy into a corresponding PAPE defined authentication policies (e.g. phishing-resisistant). Alternatively, if the SAML response message specified a LOA Authentication Context class (as per the SAML LOA profile) the OP SHOULD map into the appropriate PAPE LOA policy URI in its response to the RP.
Either way, the OP SHOULD ensure that the specific PAPE authentication policy identifier or LOA policy URI on the OpenID reponse to the RP indicates equal or less assurance than provided on the SAML response from the IdP.
If, in the future, the OP is asked to authenticate the user for a different RP, and this request requires equal or less assurance as the original request (as determined by the proxying OP), the OP MAY skip the creation of a new <AuthnRequest> to the SAML IdP and immediately issue another assertion if the original SAML assertion it received from the IdP is still valid.
------------------------------------------------------------------------ TOC <#toc>
4.2. User visits SAML SP
This scenario has the user visit a SAML SP first. The authentication at the chosen IdP is proxied through OpenID to an appropriate OP. This scenario is shown below:
+----+ +----+ +--------+ +--------+ | UA | | SP | | IdP/RP | | OP | +-+--+ +-+--+ +---+----+ +---+----+ | | | | |-------------->| | | | | | | +<- - - - - - - - | | | . | | | | +-----------------+- AuthnCont --->| | | | | | +<- - - - - - - - - - - - - - - - -| | . | | | | +-----------------+---- PAPE ----------------------->| | | | | <- - - - - - - - - - - - - - - - - - - - - - - - - -| | | | | -----------------+---- Log in -------------------->| | | | | +<- - - - - - - - - - - PAPE - - - - - - - - - - - -| . | | | | +-----------------+--------------->| | | | | | +<- - - - - - - - - AuthnCont - -| | . | | | | +---------------->| | |
------------------------------------------------------------------------ TOC <#toc>
4.2.1. Request
If the SAML authentication request contains a <RequestedAuthnContext> that the IdP is unable to satisfy, the IdP MAY proxy the request through OpenID to an OP that can.
If the SAML authentication request contains a ProxyCount value of zero on the <Scoping> element, the IDP MUST NOT proxy the request.
If the SAML authentication request has ForceAuthn = "false" and isPassive = "true", the IdP MUST specify openid.mode = "checkid_immediate" on any proxied OpenID Authentication request.
If the SAML authentication request contains an <IDPList> in the <Scoping> element, the IDP MUST respect the policy and only proxy to any OPs within the list.
If proxying, the IdP SHOULD give the User the ability to choose the OP to be used. The IdP SHOULD offer as choices those OPs that are known to satisfy the desired assurance requirements. The IdP SHOULD use a method for discovering the OP's assurance capabilities that gives it confidence in the OP's abilitiy to meet the desired assurance requriements.
In composing an OpenID authentication request message to the chosen OP, the OP should take the AuthnContext class URI from the SAML request and map into an appropriate PAPE policy value.
If the original SAML request specified one of the SAML defined authentication class URIs (e.g. OTP), the IdP SHOULD map this policy into an appropriate PAPE defined authentication policy URI (e.g. phishing-resistant).
If the original SAML request specified a LOA class URI, the IdP SHOULD fail the message and respond back to the SAML SP with a status code of urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext.
Note: is above too harsh?
Either way, the IdP MUST ensure that the specific PAPE authentication or assurance policy URI requested of the OP provides equal or greater assurance than specified on the original SAML request.
------------------------------------------------------------------------ TOC <#toc>
4.2.2. Response
Upon receiving the OpenID response from the authenticating OP, the IdP SHOULD proxy the OpenID message back to the original requesting SP using SAML.
The IdP SHOULD insert an <AuthenticatingAuthority> in the <AuthnContext> of the SAML Assertion returned to the SP. The value of this element MUST be the OP identifier.
The IdP SHOULD attempt to map any PAPE policy URIs from the OpenID message into correponding SAML Authentication Context class identifiers on the SAML <Response> message to the SP.
If the OpenID response message specified one of the PAPE-defined authentication policy URIs URI (e.g. phishing-resisistant), the IdP MAY map this policy into a corresponding SAML-defined authentication context class URIs (e.g. OTP).
Alternatively, if the OpenID response message specified a PAPE LOA policy URI, the IdP SHOULD map into the SAML Authentication Context LOA class URI in its response to the SP.
Either way, the IdP MUST SHOULD ensure that the specific SAML Authentication Context class URI on the SAML reponse to the SP indicates equal or less assurance than provided on the OpenID response from the OP.
If, in the future, the IdP is asked to authenticate the same user for a different SP, and this request requires equal or less assurance than the original request (as determined by the proxying IdP), the IdP MAY skip the creation of a new OpenID request to the OP and immediately issue another assertion if the original OpenID session is still valid.
------------------------------------------------------------------------ TOC <#toc>
5. Future Considerations
The emerging SAML LOA profile [SAMLLOA] (Cantor, S., Madsen, P., and RL. Morgan, "SAML LOA profile," October 2009.) <#SAMLLOA> defines how to bind LOA to the existing SAML authentication context mechanism, as well as allowing a SAML IdP to advertise the LOA it has been certified as being able to support. Once complete, the SAML LOA profile is expected to be relevant to the proxying use case.
------------------------------------------------------------------------ TOC <#toc>
6. Security Considerations
Say something about the proxy following a 'round down philosophy' when mapping?
------------------------------------------------------------------------ TOC <#toc>
7. References
[PAPE] Recordon, D., "Provider Authentication Policy Extension <kkkk>," March 2008 (HTML <http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html>).
[SAMLAC] Kemp, J., "SAML Authentication Context <jjjj>," March 2005 (PDF <http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf>).
[SAMLLOA] Cantor, S., Madsen, P., and RL. Morgan, "SAML LOA profile <jjjj>," October 2009 (PDF <http://www.oasis-open.org/committees/download.php/32482/sstc-saml-loa-authncontext-profile-draft-03.pdf>).
------------------------------------------------------------------------ TOC <#toc>
Authors' Addresses
Paul Madsen NTT
Tatsuki Sakushima NRI
------------------------------------------------------------------------
_______________________________________________ Dg-concordia mailing list Dg-concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia
------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.420 / Virus Database: 270.14.4/2417 - Release Date: 10/06/09 06:50:00
-- Paul Madsen e:paulmadsen @ ntt-at.com m:613-282-8647 web:connectid.blogspot.com ConnectID <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
Paul, Could you also circulate the slides you've used before to present this work? Brett McDowell | http://info.brettmcdowell.com | http://kantarainitiative.org On Tue, Oct 6, 2009 at 2:34 PM, Paul Madsen <paulmadsen@rogers.com> wrote:
Teeny correction to make in above subject line
s/OAuth/SAML/g
Paul Madsen wrote:
Hi, as discussed at Vegas, NRI & NTT have been working on the enclosed, essentially writing down the lessons learned about proxying between SAML AC & OpenID PAPE in the RSA IOP demo
We're hoping for initial discussion within the Concordia DG, with a decision as to next steps (e.g. perhaps spin up a new WG in order to publish as a KI Recommendation...) to come.
Feedback welcome
Paul -- Paul Madsen e:paulmadsen @ ntt-at.com m:613-282-8647 web:connectid.blogspot.com [image: ConnectID] <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
------------------------------
TOC <#1242b218c4185422_toc> Draft P. Madsen NTT T. Sakushima NRI October 6, 2009 Deployment Guide for Proxying Assurance between OpenID and SAML Abstract
SAML and OpenID are key federated identity protocols. Both SAML and OpenID define mechanisms in support of expressing assurance information on protocol messages, respectively Authentication Context and the Provider Authentication POlicy Extension (PAPE). In deployment scenarios that require proxying from one of the protocols to the other, it becomes necessary to map to and from the corresponding assurance mechanisms. This document provides guidance on this mapping and related issues.
------------------------------ Table of Contents
1. <#1242b218c4185422_anchor1> Requirements notation 2. <#1242b218c4185422_anchor2> Overview 2.1. <#1242b218c4185422_anchor3> SAML Authentication Context 2.2. <#1242b218c4185422_anchor4> OpenID PAPE 3. <#1242b218c4185422_anchor5> Motivation 4. <#1242b218c4185422_anchor6> Proxying 4.1. <#1242b218c4185422_anchor7> User visits OpenID RP 4.1.1. <#1242b218c4185422_anchor8> Request 4.1.2. <#1242b218c4185422_anchor9> Response 4.2. <#1242b218c4185422_anchor10> User visits SAML SP 4.2.1. <#1242b218c4185422_anchor11> Request 4.2.2. <#1242b218c4185422_anchor12> Response 5. <#1242b218c4185422_anchor13> Future Considerations 6. <#1242b218c4185422_anchor14> Security Considerations 7. <#1242b218c4185422_rfc.references1> References § <#1242b218c4185422_rfc.authors> Authors' Addresses
------------------------------ TOC <#1242b218c4185422_toc> 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
------------------------------ TOC <#1242b218c4185422_toc> 2. Overview
In the context of federated identity protocols, assurance refers to the degree of confidence a Relying Party (RP) can ascribe to the identity assertions an Identity Provider (IdP) makes regarding end-users. In the absence of legal contracts indemnifying the RP from any risk involved in accepting such assertions, an RP's confidence (and consequent willingness to accept the assertions) may be increased through knowledge of the policies & processes followed by the IdP in issuing the assertion. For instance, in a Single Sign On application, the degree of confidence the RP has in the assertion from the IdP as to the authentication status of the User may depend on a number of factors, including how the User was originally registered at the IDP, and how they were subsequently authenticated.
Notwithstanding that assurance is ultimately a continuum, it is typically categorized into levels (LOA) for practicality. Assurance frameworks (such as NIST 800 63) stipulate the required policies and procedures that an IdP must perform in order to meet defined LOA.
Both SAML & OpenID define mechanisms in support of expressing assurance information on protocol messages, respectively Authentication Context and the Provider Authentication Policy Extension (PAPE). Through these mechanisms, an RP is able to express its assurance expectations on its request message to the IdP for authentication, and the IdP is able to express the actual assurance achieved on its response message back.
In deployment scenarios that require proxying from one of the protocols to the other, it may become necessary for the proxying entity to map between the SAML and OpenID assurance mechanisms. While similar, the two mechanisms make different assumptions about expressing assurance - thereby creating the possibility of issues for the proxy. This document provides guidance to those entities playing the role of proxy on this mapping and related issues.
------------------------------ TOC <#1242b218c4185422_toc> 2.1. SAML Authentication Context
SAML Authentication Context [SAMLAC] (Kemp, J., “SAML Authentication Context,” March 2005.) <#1242b218c4185422_SAMLAC> provides a number of related mechanisms by which the SAML IDP & SP can indicate the nature of authentication, registration, proofing etc and thereby facilitate the RP establishing an appropriate level of assurance in the IDP's assertions. Authentication context is defined as the information, additional to the authentication assertion itself, that the relying party may require before it makes an entitlements decision with respect to an authentication assertion.
SAML defines authentication context classes to facilitate SPs making assurance decisions. Each class defines a proper subset of the full set of authentication contexts. Classes have been chosen as representative of the current practices and technologies for registration and authentication technologies.
------------------------------ TOC <#1242b218c4185422_toc> 2.2. OpenID PAPE
The OpenID Provider Authentication Policy Extension (PAPE) [PAPE] (Recordon, D., “Provider Authentication Policy Extension,” March 2008.)<#1242b218c4185422_PAPE>allows the RP and OP to discuss the specifics of how the user authenticated to the OP. Through PAPE, an OpenID RP is able to add to the OpenID Authentication request additional authentication requirements, specifically stipulating its preference for how the user was authenticated, and specify how long ago that authentication is allowed to have occurred.
PAPE defines 3 URIs for what are expected to be relevant authentication mechanisms.
http://schemas.openid.net/pape/policies/2007/06/phishing-resistant - An authentication mechanism where the End User does not provide a shared secret to a party potentially under the control of the Relying Party.
http://schemas.openid.net/pape/policies/2007/06/multi-factor - an authentication mechanism where the End User authenticates to the OpenID Provider by providing over one authentication factor.
http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical - An authentication mechanism where the End User authenticates to the OpenID Provider by providing over one authentication factor where at least one of the factors is a physical factor such as a hardware device or biometric.
In addition to specifying particular authentication technologies or characteristics as above, PAPE also supports more abstract LOA. It is worth noting that, while PAPE allows an OP to make a claim for a LOA on its response, PAPE does not allow the requesting RP to indicate a desired LOA on its request (although a desired LOA could be placed within the PAPE authentication policy param on the request).
------------------------------ TOC <#1242b218c4185422_toc> 3. Motivation
For SSO, both SAML and OpenID depend on an interaction between a RP and an IdP - the RP requests of the IdP that a visiting User be authenticated and the fact and nature of this authentication be returned to the RP. Neither SAML nor OpenID require that the IdP actually itself perform the authentication - in principle allowing the IdP to outsource the job just like the RP did.
Consequently, it is possible for an authentication request sent from an OpenID RP to an OpenID Provider (OP) to be proxied by that OP using SAML to a SAML IdP for the actual authentication of the User through presentation of a credential. This might be the case if the original OpenID RP were to request a higher LOA than could be satisfied by the OP which, in order to satisfy the request, would proxy the request through SAML to a SAML IdP that could satisfy the desired LOA.
Likewise, it is possible for an authentication request sent from a SAML SP to an SAML IDP to be proxied by that IdP using OpenID to a OP for the actual authentication of the User. This might be the case if the original SAML SP were to request a lower LOA than than supported by the SAML IdP which, in order to satisfy the request, would proxy the request through OpenID to an OP that could satisfy the desired LOA.
------------------------------ TOC <#1242b218c4185422_toc> 4. Proxying
Below are recommendations for the entity playing the role of protocol proxy between SAML & OpenID, differentiated by the protocol supported by the eventual consumer of the assertion.
------------------------------ TOC <#1242b218c4185422_toc> 4.1. User visits OpenID RP
This scenario has the user visit an OpenID RP first. The authentication at the chosen OP is proxied through SAML to an appropriate IdP. This scenario is shown below:
+----+ +----+ +--------+ +--------+ | UA | | RP | | OP/SP | | IdP | +-+--+ +-+--+ +---+----+ +---+----+ | | | | | | | | +<- - - - - - - - | | | . | | | | +-----------------+--- PAPE ------>| | | | | | +<- - - - - - - - - - - - - - - - -| SAML | . | | | | +-----------------+-- AuthnCont -------------------->| | | | | <- - - - - - - - - - - - - - - - - - - - - - - - - -| | | | | -----------------+---- Log in -------------------->| | | | | +<- - - - - - - - - - AuthnCont - - - - - - - - - - -| . | | | | +-----------------+--------------->| | | | | | +<- - - - - - - - - - PAPE - - - -| | . | | | | +---------------->| | |
------------------------------ TOC <#1242b218c4185422_toc> 4.1.1. Request
If the OpenID authentication request contains a PAPE policy URI that the OP is unable to satisfy, the OP MAY choose to proxy the request through SAML to an IdP that can.
If the OpenID authentication request has openid.mode = "checkid_immediate", the OP MUST specify ForceAuthn = "false" and isPassive = "true" on any proxied SAML Authentication request.
If proxying, the OP SHOULD give the User the ability to choose the SAML IdP to be used. The OP SHOULD offer as choices only those IdPs that are known to satisfy the desired assurance requirements.
Once the user has selected an IdP, the OP SHOULD attempt to remember this preference for future use.
In composing a SAML AuthnRequest message to the chosen IdP, the OP should take the PAPE policy URI from the OpenID request and map into an appropriate SAML <RequestedAuthnContext><AuthnContextClassRef> value.
If the original OpenID request specified one of the PAPE defined authentication policies (e.g. phishing-resisistant), the OP MAY map this policy into an appropriate SAML-defined Authentication Context class URI (e.g. OTP) as the value of the <RequestedAuthnContext>. Alternatively, the OP MAY map the requested PAPE authentication policy into an appropriate LOA Authentication context class.
Either way, the OP MUST ensure that the specific authentication class or the general LOA requested of the SAML IdP provides equal or greater assurance than specified on the original OpenID request.
------------------------------ TOC <#1242b218c4185422_toc> 4.1.2. Response
Upon receiving the SAML <Response> message from the IdP, the OP SHOULD proxy the SAML message back to the original requesting RP using OpenID. The message MUST be constructed as an OpenID response to the original OpenID request.
If the SAML Response contains a <ProxyRestriction> element with a Count of zero, the IdP MUST NOT proxy the Response message to the OpenID RP. Instead, the OP SHOULD send a negative assertion with openid.mode = "cancel".
If proxying, the OP SHOULD attempt to map any SAML Authentication Context class identifiers from the SAML message into correponding PAPE identifiers on the OpenID response message to the RP.
If the SAML response message specified one of the SAML-defined Authentication Context class URI (e.g. OTP), the OP MAY map this policy into a corresponding PAPE defined authentication policies (e.g. phishing-resisistant). Alternatively, if the SAML response message specified a LOA Authentication Context class (as per the SAML LOA profile) the OP SHOULD map into the appropriate PAPE LOA policy URI in its response to the RP.
Either way, the OP SHOULD ensure that the specific PAPE authentication policy identifier or LOA policy URI on the OpenID reponse to the RP indicates equal or less assurance than provided on the SAML response from the IdP.
If, in the future, the OP is asked to authenticate the user for a different RP, and this request requires equal or less assurance as the original request (as determined by the proxying OP), the OP MAY skip the creation of a new <AuthnRequest> to the SAML IdP and immediately issue another assertion if the original SAML assertion it received from the IdP is still valid.
------------------------------ TOC <#1242b218c4185422_toc> 4.2. User visits SAML SP
This scenario has the user visit a SAML SP first. The authentication at the chosen IdP is proxied through OpenID to an appropriate OP. This scenario is shown below:
+----+ +----+ +--------+ +--------+ | UA | | SP | | IdP/RP | | OP | +-+--+ +-+--+ +---+----+ +---+----+ | | | | |-------------->| | | | | | | +<- - - - - - - - | | | . | | | | +-----------------+- AuthnCont --->| | | | | | +<- - - - - - - - - - - - - - - - -| | . | | | | +-----------------+---- PAPE ----------------------->| | | | | <- - - - - - - - - - - - - - - - - - - - - - - - - -| | | | | -----------------+---- Log in -------------------->| | | | | +<- - - - - - - - - - - PAPE - - - - - - - - - - - -| . | | | | +-----------------+--------------->| | | | | | +<- - - - - - - - - AuthnCont - -| | . | | | | +---------------->| | |
------------------------------ TOC <#1242b218c4185422_toc> 4.2.1. Request
If the SAML authentication request contains a <RequestedAuthnContext> that the IdP is unable to satisfy, the IdP MAY proxy the request through OpenID to an OP that can.
If the SAML authentication request contains a ProxyCount value of zero on the <Scoping> element, the IDP MUST NOT proxy the request.
If the SAML authentication request has ForceAuthn = "false" and isPassive = "true", the IdP MUST specify openid.mode = "checkid_immediate" on any proxied OpenID Authentication request.
If the SAML authentication request contains an <IDPList> in the <Scoping> element, the IDP MUST respect the policy and only proxy to any OPs within the list.
If proxying, the IdP SHOULD give the User the ability to choose the OP to be used. The IdP SHOULD offer as choices those OPs that are known to satisfy the desired assurance requirements. The IdP SHOULD use a method for discovering the OP's assurance capabilities that gives it confidence in the OP's abilitiy to meet the desired assurance requriements.
In composing an OpenID authentication request message to the chosen OP, the OP should take the AuthnContext class URI from the SAML request and map into an appropriate PAPE policy value.
If the original SAML request specified one of the SAML defined authentication class URIs (e.g. OTP), the IdP SHOULD map this policy into an appropriate PAPE defined authentication policy URI (e.g. phishing-resistant).
If the original SAML request specified a LOA class URI, the IdP SHOULD fail the message and respond back to the SAML SP with a status code of urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext.
Note: is above too harsh?
Either way, the IdP MUST ensure that the specific PAPE authentication or assurance policy URI requested of the OP provides equal or greater assurance than specified on the original SAML request.
------------------------------ TOC <#1242b218c4185422_toc> 4.2.2. Response
Upon receiving the OpenID response from the authenticating OP, the IdP SHOULD proxy the OpenID message back to the original requesting SP using SAML.
The IdP SHOULD insert an <AuthenticatingAuthority> in the <AuthnContext> of the SAML Assertion returned to the SP. The value of this element MUST be the OP identifier.
The IdP SHOULD attempt to map any PAPE policy URIs from the OpenID message into correponding SAML Authentication Context class identifiers on the SAML <Response> message to the SP.
If the OpenID response message specified one of the PAPE-defined authentication policy URIs URI (e.g. phishing-resisistant), the IdP MAY map this policy into a corresponding SAML-defined authentication context class URIs (e.g. OTP).
Alternatively, if the OpenID response message specified a PAPE LOA policy URI, the IdP SHOULD map into the SAML Authentication Context LOA class URI in its response to the SP.
Either way, the IdP MUST SHOULD ensure that the specific SAML Authentication Context class URI on the SAML reponse to the SP indicates equal or less assurance than provided on the OpenID response from the OP.
If, in the future, the IdP is asked to authenticate the same user for a different SP, and this request requires equal or less assurance than the original request (as determined by the proxying IdP), the IdP MAY skip the creation of a new OpenID request to the OP and immediately issue another assertion if the original OpenID session is still valid.
------------------------------ TOC <#1242b218c4185422_toc> 5. Future Considerations
The emerging SAML LOA profile [SAMLLOA] (Cantor, S., Madsen, P., and RL. Morgan, “SAML LOA profile,” October 2009.) <#1242b218c4185422_SAMLLOA>defines how to bind LOA to the existing SAML authentication context mechanism, as well as allowing a SAML IdP to advertise the LOA it has been certified as being able to support. Once complete, the SAML LOA profile is expected to be relevant to the proxying use case.
------------------------------ TOC <#1242b218c4185422_toc> 6. Security Considerations
Say something about the proxy following a 'round down philosophy' when mapping?
------------------------------ TOC <#1242b218c4185422_toc> 7. References [PAPE] Recordon, D., “Provider Authentication Policy Extension <http://kkkk>,” March 2008 (HTML<http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html> ). [SAMLAC] Kemp, J., “SAML Authentication Context <http://jjjj>,” March 2005 (PDF<http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf> ). [SAMLLOA] Cantor, S., Madsen, P., and RL. Morgan, “SAML LOA profile<http://jjjj>,” October 2009 (PDF<http://www.oasis-open.org/committees/download.php/32482/sstc-saml-loa-authncontext-profile-draft-03.pdf> ). ------------------------------ TOC <#1242b218c4185422_toc> Authors' Addresses Paul Madsen NTT Tatsuki Sakushima NRI
------------------------------
_______________________________________________ Dg-concordia mailing listDg-concordia@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-concordia
------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.420 / Virus Database: 270.14.4/2417 - Release Date: 10/06/09 06:50:00
-- Paul Madsen e:paulmadsen @ ntt-at.com m:613-282-8647 web:connectid.blogspot.com [image: ConnectID] <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
_______________________________________________ Dg-concordia mailing list Dg-concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia
participants (2)
-
Brett McDowell -
Paul Madsen