| TOC |
|
This document specifies a SAMLv2 lightweight Web Browser Single Sign-On Profile that matches the functionality in OpenID. It is accomplished by profiling the SAMLv2 Lightweight Web Browser SSO Profile in combination with the SAML HTTP POST SimpleSign binding.
1.
Introduction
2.
Terminology
3.
Specification Scope
4.
SAML Lightweight SSO Profiles
4.1.
OpenID SAMLv2 Lightweight SSO Profile
5.
Example SAML Assertion
6.
Security Considerations
7.
Contributors
8.
Acknowledgments
9.
IANA Considerations
10.
Open Issues
11.
Normative References
§
Author's Address
| TOC |
This document specifies a SAMLv2 lightweight Web Browser Single Sign-On Profile that matches the functionality in OpenID. It is accomplished by profiling the SAMLv2 Lightweight Web Browser SSO Profile in combination with the SAML HTTP POST SimpleSign binding.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
The scope of this specification is:
| TOC |
This section defines one SAML profile:
The "OpenID SAMLv2 Lightweight SSO Profile"
NOTE: The below profile is incomplete at this time in that, e.g., it doesn't yet address the case of the OpenID "stateless" authn exchange where the RP subsequently submits the message he received from the UA back to the OP/IDP for signature verification. I do not believe that there are any unsurmountable difficulties to encourter in completing the mapping of OpenID to this OpenID/SAML profile.
| TOC |
This specification is comprised of simple profiles of several other specifications in order to realize the goal given above in Section 3 (Specification Scope).
Also, it is assumed that the user is using a standard vanilla browser and can authenticate with the identity provider by some means outside the scope of this profile.
The profile begins with initiation and discovery and optionally key exchange as specified in [OpenID.openid‑authentication‑2_0‑12] (OpenID, “OpenID Authentication 2.0 - Draft 12,” August 2007.) Sections 7 and 8. See also Figure 1 (Initiation, Discovery, and Key Exchange).
+-------------+ | Principal's | | Site | | ..or.. | +----+ +----+ +--------+ | XRI | | UA | | RP | | OP/IDP | | Authority | +-+--+ +-+--+ +---+----+ +-----+-------+ | | | | | | | | | 1. User Agent access | | | | RP Site, typcially via| | | | GET | | | |---------------------->| | | | | | | | | | | | | | | | 2. RP returns a page | | | | with prompt for Princ | | | | to use to enter OpenId| | | |<----------------------| | | | | | | | 3. UA typically POSTs | | | | Princ's OpenId string | | | | to RP | | | |---------------------->| 4. RP resolves OpenId| | | | string via Yadis, | | | | XRI, or HTTP GET res-| | | | Olution, yielding URL| | | | of Princ's OP/IDP | | | |<--------------------------------->| | | | | | | | | | | | | | | 5. POST DH params, | | | | openid.mode = assoc. | | | |--------------------->| | | | | | | | | | | | 6. OP/IDP returns | | | | shared secret and | | | | assoc_handle | | | |<---------------------| | | | | |
Figure 1: Initiation, Discovery, and Key Exchange
The profile continues with Step 3 of the SAMLv2 Lightweight Web Browser SSO Profile (SAML lSSO) [I‑D.hodges‑saml‑lsso] (Hodges, J. and S. Cantor, “SAMLv2 Lightweight Web Browser SSO Profile,” September 2007.), which is specified in Section "5.1.4.3. <AuthnRequest> Is Issued by Service Provider to Identity Provider" of that spec.Note that the following alterations are to be made to the SAML lSSO profile:
The effect of the openid.mode parameter is effected by the "IsPassive" XML attribute of the <AuthnRequest> message.
The <Subject> element in the <AuthnRequest> message is used to convey the openid.claimed_id, if present, and which is described in section 9.1 of [OpenID.openid‑authentication‑2_0‑12] (OpenID, “OpenID Authentication 2.0 - Draft 12,” August 2007.).
The openid.identity value, if present, and also described in section 9.1 of [OpenID.openid‑authentication‑2_0‑12] (OpenID, “OpenID Authentication 2.0 - Draft 12,” August 2007.) is conveyed via an extension element..
..which is included in the <AuthnRequest> message by placing it in the optional <samlp:Extensions> element. See [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) section 3.2.1.<element name="openid.identity" type="saml:NameIDType"\>
The openid.assoc_handle value, if present, and also described in section 9.1 of [OpenID.openid‑authentication‑2_0‑12] (OpenID, “OpenID Authentication 2.0 - Draft 12,” August 2007.) is conveyed via an extension element..
..which is included in the <AuthnRequest> message by placing it in the optional <samlp:Extensions> element. See [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) section 3.2.1.<element name="openid.assoc_handle" type="String"\>
The openid.return_to value is effectively conveyed in the AssertionConsumerServiceURL XML attribute of the <AuthnRequest> message.
The shared secret key, established above, if any, is employed if the <AuthnRequest> and <Response> messages are to be signed. The key is refered to in <ds:keyinfo> by the name of "openid.assoc_key".
Please refer to Figure 2 (SAML-based Authn Exchange).
+----+ +----+ +--------+ | UA | | RP | | OP/IDP | +-+--+ +-+--+ +---+----+ | | | | | | | 3. <AuthnRequest> msg | | | issued by RP to OP/IDP| | +<- - - - - - - - - - - - | | . | (redirect to OP/IDP) | | . | | | +-------------------------+--------------------->| | | | | | | | | | | | | | 4. Identity Provider identifies Principal | | (methods vary, details not shown) | |<============================================>| | | | | | | | | | | 5. <Response> message | | | issued by OP/IDP to RP| | +<- - - - - - - - - - - - - - - - - - - - - - - -| . | (redirect to RP) | | . | | | +------------------------>| | | | | | | | | | | | 6. Based on the OP/IDP| | | identifying (or not) | | | the Principal, the RP | | | either returns the | | | resource or an (HTTP) | | | error | | |<----------------------| | | | | | | | | | | | | |
Figure 2: SAML-based Authn Exchange
| TOC |
This section presents an example SAML assertion.
In the first example, Figure 3 (Unsigned SAML Assertion Illustrating Conveyance of Subject Attribute), the assertion is attesting with respect to the subject (lines 7-15) "Alice@example.com" (line 11). The validity conditions are expressed in lines 16-23, via both a validity period expressed as temporal endpoints, and an "audience restriction" stating that this assertion's semantics are valid for only the relying party named "example2.com". Also, the assertion's issuer is noted in lines 4-5. The authentication statement in lines 24-30 indicate that the issuer is attesting to having authenticated the subject using the mechanism denoted in the <AuthnContext> element.
1 <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" 2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0" 3 xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> 4 <Issuer> 5 example.com 6 </Issuer> 7 <Subject> 8 <NameID 9 Format= 10 "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> 11 Alice@example.com 12 </NameID> 13 <SubjectConfirmation 14 Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/> 15 </Subject> 16 <Conditions NotBefore="2003-04-17T00:46:02Z" 17 NotOnOrAfter="2003-04-17T00:51:02Z"> 18 <AudienceRestriction> 19 <Audience> 20 example2.com 21 </Audience> 22 </AudienceRestriction> 23 </Conditions> 24 <AuthnStatement AuthnInstant="2003-04-17T00:46:00Z"> 25 <AuthnContext> 26 <AuthnContextClassRef> 27 urn:oasis:names:tc:SAML:2.0:ac:classes:Password 28 </AuthnContextClassRef> 29 </AuthnContext> 30 </AuthnStatement> 31 </Assertion>
| Figure 3: Unsigned SAML Assertion
Illustrating Conveyance of
Subject Attribute |
| TOC |
Security considerations for this specification is an amalgamation (i.e. union) of the sec cons found in [OASIS.saml‑sec‑consider‑2.0‑os] (Hirsch, F., Philpott, R., and E. Maler, “Security and Privacy Considerations for the OASIS Security Markup Language (SAML) V2.0,” March 2005.), [OpenID.openid‑authentication‑2_0‑12] (OpenID, “OpenID Authentication 2.0 - Draft 12,” August 2007.), and [I‑D.hodges‑saml‑lsso] (Hodges, J. and S. Cantor, “SAMLv2 Lightweight Web Browser SSO Profile,” September 2007.).
| TOC |
@@ TODO.
| TOC |
@@ TODO.
| TOC |
This document contains a number of IANA considerations. A future version of this document will list them in this section.
| TOC |
None at this time.
| TOC |
| TOC |
| Jeff Hodges | |
| NeuStar | |
| 2000 Broadway Street | |
| Redwood City, CA 94063 | |
| US | |
| Email: | Jeff.Hodges@neustar.biz |