TOC 
A OpenID-SAML WhitepaperJ. Hodges
 NeuStar
 September 21, 2007


OpenID-SAML Lightweight Web Browser SSO Profile - Draft 02

Abstract

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.



Table of Contents

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 

1.  Introduction

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 

2.  Terminology

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 

3.  Specification Scope

The scope of this specification is:



 TOC 

4.  SAML Lightweight SSO Profiles

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 

4.1.  OpenID SAMLv2 Lightweight SSO Profile

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

<element name="openid.identity" type="saml:NameIDType"\>

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

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

<element name="openid.assoc_handle" type="String"\>

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

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 

5.  Example SAML Assertion

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 

6.  Security Considerations

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 

7.  Contributors

@@ TODO.



 TOC 

8.  Acknowledgments

@@ TODO.



 TOC 

9.  IANA Considerations

This document contains a number of IANA considerations. A future version of this document will list them in this section.



 TOC 

10.  Open Issues

None at this time.



 TOC 

11. Normative References

[I-D.hodges-saml-lsso] Hodges, J. and S. Cantor, “SAMLv2 Lightweight Web Browser SSO Profile,” Unaffiliated Draft draft-hodges-saml-lsso-02, September 2007.
[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,” OASIS Standard saml-core-2.0-os, March 2005.
[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,” OASIS Standard saml-sec-consider-2.0-os, March 2005.
[OASIS.sstc-saml-binding-simplesign-cd-02] Hodges, J. and S. Cantor, “SAMLv2: HTTP POST "SimpleSign" Binding,” OASIS SSTC Committee Draft sstc-saml-binding-simplesign-cd-02, September 2007.
[OpenID.openid-authentication-2_0-12] OpenID, “OpenID Authentication 2.0 - Draft 12,” Draft openid-authentication-2_0-12, August 2007.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).


 TOC 

Author's Address

  Jeff Hodges
  NeuStar
  2000 Broadway Street
  Redwood City, CA 94063
  US
Email:  Jeff.Hodges@neustar.biz