TOC 
NoneJ. Hodges
Internet-DraftNeuStar
Expires: March 24, 2008S. Cantor
 Internet2
 September 21, 2007


SAMLv2 Lightweight Web Browser SSO Profile
draft-hodges-saml-lsso-02.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on March 24, 2008.

Copyright Notice

Copyright © The IETF Trust (2007).

Abstract

This document specifies a SAMLv2 lightweight Web Browser Single Sign-On Profile. This profile is modeled on the OASIS SAMLv2 Web Browser SSO profile, adding various constraints, and using a new lighterweight SAMLv2 HTTP POST binding offering an optional signature technique that is more simple-to-implement than the also optional XML Digital Signature approach.



Table of Contents

1.  Introduction
2.  Terminology
3.  Specification Scope
4.  SAML Introduction
    4.1.  SAML Assertions
    4.2.  Abstract Request/Response Protocol
5.  SAML Lightweight SSO Profiles
    5.1.  Lightweight Web Browser SSO SAML Profile
        5.1.1.  Differences from SAMLv2 Web Browser SSO Profile
        5.1.2.  Required Information
        5.1.3.  Profile Overview
        5.1.4.  Profile Description
        5.1.5.  Use of Authentication Request Protocol
        5.1.6.  Unsolicited Responses
        5.1.7.  Use of Metadata
    5.2.  Example SAML Assertion
    5.3.  Security Considerations
        5.3.1.  Unintended Principal Data Leakage
        5.3.2.  Man-in-the-middle Attacks and Stolen Assertions
        5.3.3.  Forged Assertion
    5.4.  Contributors
    5.5.  Acknowledgments
    5.6.  IANA Considerations
    5.7.  Open Issues
    5.8.  Change Log
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

This document specifies a SAMLv2 lightweight Web Browser Single Sign-On Profile. This profile is modeled on the OASIS SAMLv2 Web Browser SSO profile, adding various constraints, and using a new lighterweight SAMLv2 HTTP POST binding offering an optional signature technique that is more simple-to-implement than the also optional XML Digital Signature approach.

XML digital signature (XMLdsig) [W3C.xmldsig‑core] (Eastlake, D., Reagle , J., and D. Solo, “XML-Signature Syntax and Processing,” October 2000.) is made optional because it is asserted by various implementors that implementation support for it is essentially non-existent in so-called "scripting" environments, e.g. PERL/PYTHON/PHP/Ruby, and/or different implementations of it are not very interoperable as yet, due to the inherent complexity of the specificaion and its required behaviors.

Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML-based framework for creating and exchanging security information. [OASIS.sstc‑saml‑exec‑overview‑2.0‑cd‑01] (Madsen, P. and E. Maler, “SAML V2.0 Executive Overview,” April 2005.) and [OASIS.sstc‑saml‑tech‑overview‑2.0‑cd‑01] (Ragouzis, N., Hughes, J., Philpott, R., Maler, E., Madsen, P., and T. Scavo, “Security Assertion Markup Language (SAML) V2.0 Technical Overview,” March 2007.) provide non-normative overviews of SAMLv2. The SAMLv2 specification set is normatively defined by [OASIS.saml‑conformance‑2.0‑os] (Mishra, P., Philpott, R., and E. Maler, “Conformance Requirements for the Security Assertion Markup Language (SAML) V2.0,” March 2005.).



 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:

The following are outside the scope of this specification:



 TOC 

4.  SAML Introduction

SAML [OASIS.sstc‑saml‑exec‑overview‑2.0‑cd‑01] (Madsen, P. and E. Maler, “SAML V2.0 Executive Overview,” April 2005.) [OASIS.sstc‑saml‑tech‑overview‑2.0‑cd‑01] (Ragouzis, N., Hughes, J., Philpott, R., Maler, E., Madsen, P., and T. Scavo, “Security Assertion Markup Language (SAML) V2.0 Technical Overview,” March 2007.) defines an XML-based framework for exchanging "security assertions" between entities. In the course of making, or relying upon such assertions, SAML system entities may use SAML protocols, or other protocols, to communicate regarding an assertion itself, or the subject of an assertion.

Thus one can employ SAML to encode statements such as "Alice has these profile attributes and her domain's certificate is available over there, and I'm making this statement, and here's who I am." Then one can cause such an assertion to be conveyed to some party who can then rely on it in some fashion for some purpose, for example input it into some local policy evaluation for access to some resource. This is done in a particular "context of use". Such a context of use could be, for example, deciding whether to accept and act upon a SIP-based invitation to initiate a communication session.

The specification of how SAML is employed in a particular context of use is known as a "SAML profile". The specification of how SAML assertions and/or protocol messages are concretely conveyed in, or over, another protocol is known as a "SAML Binding". Typically, a SAML profile specifies the SAML binding(s) that are to be used in its context. Specification of both or either SAML profiles and SAML bindings are by definition built on the foundation provided by the SAML specifications, especially the SAML Assertions and Protocols, aka "SAML Core", specification [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.).

There is an additional subtle aspect of SAML profiles that is worth highlighting -- the notion of a "SAML assertion profile". A SAML assertion profile is the specification of the assertion contents in the context of a particular SAML profile. It is possibly further qualified by a particular implementation and/or deployment context. Condensed examples of SAML assertion profiles are:

The primary facets of SAML itself are:

We describe each in turn below:



 TOC 

4.1.  SAML Assertions

A SAML assertion is a package of information including issuer and subject, conditions and advice, and/or attribute statements, and/or authentication statements and/or other statements. Statements may or may not be present. The SAML assertion "container" itself contains the following information:

Issuing information:

Who issued the assertion, when was it issued and the assertion identifier.

Subject information:

The name of the subject, the security domain and optional subject information, like public key.

Conditions under which the assertion is valid:

Special kind of conditions like assertion validity period, audience restriction and target restriction.

Additional advice:

Explaining how the assertion was made, for example.

In terms of SAML assertions containing SAML attribute statements or SAML authentication statements, here are explanatory examples:

With a SAML assertion containing a SAML attribute statement, an issuing authority is asserting that the subject is associated with certain attributes with certain subject profile attribute values. For example, user jon@cs.example.com is associated with the attribute "Department", which has the value "Computer Science".

With a SAML assertion containing a SAML authentication statement, an issuing authority is asserting that the subject was authenticated by certain means at a certain time.

With a SAML assertion containing both a SAML attribute statement and a SAML authentication statement, an issuing authority is asserting the union of the above.



 TOC 

4.2.  Abstract Request/Response Protocol

SAML defines an abstract request/response protocol for obtaining assertions. See Section 3 "SAML Protocols" of [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.). A request asks for an assertion. A response returns the requested assertion or an error. This abstract protocol may then be cast into particular contexts of use by binding it to specific underlying protocols, e.g., HTTP or SIP, and "profiling" it for the specific use case at hand. The SAML HTTP-based web single sign-on profile is one such example (see Section 4.1 Web Browser SSO Profile of [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.)).



 TOC 

5.  SAML Lightweight SSO Profiles

This section defines one SAML profile:

The "Lightweight Web Browser SSO SAML Profile"



 TOC 

5.1.  Lightweight Web Browser SSO SAML Profile

In the scenario supported by the web browser SSO profile, a web user either accesses a resource at a service provider, or accesses an identity provider such that the service provider and desired resource are understood or implicit. The web user authenticates (or has already authenticated) to the identity provider, which then produces an authentication assertion (possibly with input from the service provider) and the service provider consumes the assertion to establish a security context for the web user. During this process, a name identifier might also be established between the providers for the principal, subject to the parameters of the interaction and the consent of the parties.

To implement this scenario, a profile of the SAML Authentication Request protocol is used [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.), in conjunction with the HTTP POST-SimpleSign binding [OASIS.sstc‑saml‑binding‑simplesign‑cd‑02] (Hodges, J. and S. Cantor, “SAMLv2: HTTP POST "SimpleSign" Binding,” September 2007.).

It is assumed that the user is using a standard commercial browser and can authenticate to the identity provider by some means outside the scope of SAML.



 TOC 

5.1.1.  Differences from SAMLv2 Web Browser SSO Profile

This profile is similar to the Web Browser SSO Profile in [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.). Below we list the most salient differences between them, from the perspective of this profile:

Employs the HTTP POST-SimpleSign SAML binding, rather than the other bindings specified in [OASIS.saml‑bindings‑2.0‑os] (Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Maler, “Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.), thus removing the binding-layer dependency on XMLdsig [W3C.xmldsig‑core] (Eastlake, D., Reagle , J., and D. Solo, “XML-Signature Syntax and Processing,” October 2000.). Also, this profile does not otherwise reference [W3C.xmldsig‑core] (Eastlake, D., Reagle , J., and D. Solo, “XML-Signature Syntax and Processing,” October 2000.) from the profile itself.

Various simplifications to the option settings in the <AuthnRequest> message:

AllowCreate is always "true".

<Subject> and <Conditions> are disallowed.

Only a single assertion is returned.

Requirements for the identity provider to validate the service provider's assertion consumer service are relaxed.

Various security/trust characteristics inherited as a result of use of the SimpleSign binding [OASIS.sstc‑saml‑binding‑simplesign‑cd‑02] (Hodges, J. and S. Cantor, “SAMLv2: HTTP POST "SimpleSign" Binding,” September 2007.), namely:

Cryptographically-based security is entirely OPTIONAL with the SimpleSign binding (and thus with this lSSO SAML profile).

NOTE: if no security mechanisms are employed, then there is essentially no runtime assurance as to the identity of any of the communicating entities.



 TOC 

5.1.2.  Required Information

The information given in this section is similar to the info provided when registering something, a MIME Media Type, say, with IANA. In this case, it is for registering this profile with the OASIS SSTC. See Section 2 "Specification of Additional Profiles" in [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.).

Identification:

urn:ietf:params:?:?
@@ NOTE:
This URN must be agreed upon, and then registered with IANA per [RFC3553] (Mealling, M., Masinter, L., Hardie, T., and G. Klyne, “An IETF URN Sub-namespace for Registered Protocol Parameters,” June 2003.).
Contact Information:

@@ someone's or something's contact info goes here
SAML Confirmation Method Identifiers:

@@ note which ones we use in text below here
Description:

Given below.
Updates:

None.



 TOC 

5.1.3.  Profile Overview

Figure 1 (Basic flow for achieving SSO) illustrates this profile's overall protocol flow. The following steps correspond to the labeled interactions in the figure. Within an individual step, there may be one or more actual message exchanges depending upon the protocol binding employed for that particular step and other implementation-dependent behavior.




    +----------+         +----------------+    +-------------------+
    |User Agent|         |Service Provider|    | Identity Provider |
    +----+-----+         +-------+--------+    +--------+----------+
         |                       |                      |
         |                       |                      |
         | 1. User Agent attempts|                      |
         | to access some resource                      |
         | at the Service Provider  [Do I have a        |
         |                       |  security context    |
         |---------------------->|  for this UA? Hm,    |
         |                       |  no, so I'm going    |
         |                       |  to establish one..] |
         |                       |                      |
         |                       |  2.Service Provider  |
         |                       |  determines          |
         |                       |  Identity Provider   |
         |                       |  to use (methods     |
         |                       |  vary, details not   |
         |                       |  shown)              |
         |                       |                      |
         | 3. <AuthnRequest> msg |                      |
         | issued by Service Pro-|                      |
         | vider to Identity Pro-|                      |
         | vider                 |                      |
       +<- - - - - - - - - - - - |                      |
       . |   (redirect to IDP)   |                      |
       . |                       |                      |
       +-------------------------+--------------------->|
         |                       |                      |
         |                       |                      |
         |                       |                      |
         |                       |                      |
         | 4. Identity Provider identifies Principal    |
         | (methods vary, details not shown)            |
         |<============================================>|
         |                       |                      |
         |                       |                      |
         |                       |                      |
         | 5. <Response> message |                      |
         | issued by Identity    |                      |
         | Provider to Service   |                      |
         | Provider              |                      |
       +<- - - - - - - - - - - - - - - - - - - - - - - -|
       . |   (redirect to SP)    |                      |
       . |                       |                      |
       +------------------------>|                      |
         |                       |                      |
         |                       |                      |
         |                       |                      |
         | 6. Based on the Iden- |                      |
         | tity Provider identify-                      |
         | ing (or not) the Prin-|                      |
         | cipal, the Service Pro-                      |
         | vider either returns  |                      |
         | the resource or an    |                      |
         | (HTTP) error          |                      |
         |<----------------------|                      |
         |                       |                      |
         |                       |                      |
         |                       |                      |
         |                       |                      |

 Figure 1: Basic flow for achieving SSO 

Step 1.
HTTP Request to Service Provider
In step 1, the principal, via an HTTP User Agent, makes an HTTP request for a secured resource at the service provider without a security context.
Step 2.
Service Provider Determines Identity Provider
In step 2, the service provider obtains the location of an endpoint at an identity provider for the authentication request protocol that supports its preferred binding. The means by which this is accomplished is implementation-dependent. The service provider MAY use the SAML identity provider discovery profile described in [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) or any other means of identity provider discovery.
Step 3.
<AuthnRequest> issued by Service Provider to Identity Provider
In step 3, the service provider issues an <AuthnRequest> message to be delivered by the user agent to the identity provider. The HTTP POST-SimpleSign binding MUST be used to transfer the message to the identity provider through the user agent.
Step 4.
Identity Provider identifies Principal
In step 4, the principal is identified by the identity provider by some means outside the scope of this profile. This may require a new act of authentication, or it may reuse an existing authenticated session, where said authenticated session state is maintained in some unspecified (herein) manner. A common means is for the user agent to maintain session state local to the identity provider via the means of "cookies" [RFC2965] (Kristol, D. and L. Montulli, “HTTP State Management Mechanism,” October 2000.).
Step 5.
Identity Provider issues <Response> to Service Provider
In step 5, the identity provider issues a <Response> message to be delivered by the user agent to the service provider. The HTTP POST-SimpleSign binding MUST be used to transfer the message to the service provider through the user agent. The message may indicate an error, or will include (at least) an authentication assertion.
Step 6.
Service Provider grants or denies access to Principal
In step 6, having received the response from the identity provider, the service provider can respond to the principal's user agent with its own error, or can establish its own security context for the principal and return the requested resource.

Note that an identity provider can initiate this profile at step 5 and issue a <Response> message to a service provider without the preceding steps, see Section 5.1.6 (Unsolicited Responses), below.



 TOC 

5.1.4.  Profile Description

The following sections provide detailed definitions of the individual profile steps. If the profile is initiated by the service provider, start with Section 5.1.4.1 (HTTP Request to Service Provider). If initiated by the identity provider, start with Section 5.1.4.5 (Identity Provider Issues <Response> to Service Provider). In the descriptions below, the following are referred to:

Single Sign-On Service

This is the authentication request protocol endpoint at the identity provider to which the <AuthnRequest> message is delivered by the user agent.

Assertion Consumer Service

This is the authentication request protocol endpoint at the service provider to which the <Response> message is delivered by the user agent.



 TOC 

5.1.4.1.  HTTP Request to Service Provider

In this OPTIONAL step, if the first access is to the service provider, an arbitrary request for a resource can initiate the profile. There are no restrictions on the form of the request. The service provider is free to use any means it wishes to associate the subsequent interactions with the original request. Each of the bindings provide a RelayState mechanism that the service provider MAY use to associate the profile exchange with the original request. The service provider SHOULD reveal as little of the request as possible in the RelayState value unless the use of the profile does not require such privacy measures.



 TOC 

5.1.4.2.  Service Provider Determines Identity Provider

This step is implementation-dependent. The service provider MAY use the SAML identity provider discovery profile, described in [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.). The service provider MAY also choose to redirect the user agent to another service that is able to determine an appropriate identity provider. In such a case, the service provider may issue an <AuthnRequest> (as in the next step) to this service to be relayed to the identity provider, or it may rely on the intermediary service to issue an <AuthnRequest> message on its behalf.



 TOC 

5.1.4.3.  <AuthnRequest> Is Issued by Service Provider to Identity Provider

Once an identity provider is selected, the location of its single sign-on service is determined. Metadata (as in [OASIS.saml‑metadata‑2.0‑os] (Cantor, S., Moreh, J., Philpott, R., and E. Maler, “Metadata for the Security Assertion Markup Language (SAML) V2.0,” March 2005.)) MAY be used for this purpose. In response to an HTTP request by the user agent, an HTTP response is returned containing an <AuthnRequest> message, to be delivered to the identity provider's single sign-on service, by the user agent.

The exact format of this HTTP response and the subsequent HTTP request to the single sign-on service is defined by the SAML binding used. This profile mandates use of [OASIS.sstc‑saml‑binding‑simplesign‑cd‑02] (Hodges, J. and S. Cantor, “SAMLv2: HTTP POST "SimpleSign" Binding,” September 2007.). Profile-specific rules for the contents of the <AuthnRequest> message are included in Section 5.1.5.1 (<AuthnReq> Usage).

HTTP exchanges in this step SHOULD be made over either TLS [RFC4346] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.) or SSL [SSL3] (Frier, A., Karlton, P., and P. Kocher, “The SSL 3.0 Protocol,” November 1996.) to maintain confidentiality and message integrity. The <AuthnRequest> message SHOULD be signed, using the "SimpleSign technique" specified in the binding specification [OASIS.sstc‑saml‑binding‑simplesign‑cd‑02] (Hodges, J. and S. Cantor, “SAMLv2: HTTP POST "SimpleSign" Binding,” September 2007.).

The identity provider MUST process the <AuthnRequest> message as described in [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.). This may constrain the subsequent interactions with the user agent, for example if the IsPassive attribute is untilized.



 TOC 

5.1.4.4.  Identity Provider Identifies Principal

At any time during the previous step or subsequent to it, the identity provider MUST establish the identity of the principal (unless it returns an error to the service provider). The ForceAuthn <AuhnRequest> attribute, if present with a value of "true", obligates the identity provider to freshly establish this identity, rather than relying on an existing session it may have with the principal. Otherwise, and in all other respects, the identity provider may use any means to authenticate the user agent, subject to any requirements included in the <AuhnRequest> in the form of the <RequestedAuthnContext> element.



 TOC 

5.1.4.5.  Identity Provider Issues <Response> to Service Provider

Regardless of the success or failure of the <AuthnRequest>, the identity provider SHOULD produce an HTTP response to the user agent containing a <Response> message, depending on the SAML binding used, to be delivered to the service provider's assertion consumer service.

The exact format of this HTTP response and the subsequent HTTP request to the assertion consumer service is defined by the SAML binding used. Profile-specific rules on the contents of the <Response> are included in Section 5.1.5.2 (<Response> Usage and Assertion Profile). Since the HTTP POST binding is used in this profile, the <Response> message is delivered directly to the service provider in this step.

The location of the assertion consumer service MAY be determined using metadata (as in [OASIS.saml‑metadata‑2.0‑os] (Cantor, S., Moreh, J., Philpott, R., and E. Maler, “Metadata for the Security Assertion Markup Language (SAML) V2.0,” March 2005.)). The identity provider MAY employ some out-of-scope means to establish that this location is in fact controlled by the service provider. A service provider MAY indicate the SAML binding and the specific assertion consumer service to use in its <AuthnRequest> and the identity provider SHOULD honor them if it can.

The HTTP requests in this step SHOULD be made over TLS [RFC4346] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.) to maintain confidentiality and message integrity. The <Response> message SHOULD be signed, using the "SimpleSign technique" specified in the binding specification [OASIS.sstc‑saml‑binding‑simplesign‑cd‑02] (Hodges, J. and S. Cantor, “SAMLv2: HTTP POST "SimpleSign" Binding,” September 2007.).

The service provider MUST process the <Response> message and any enclosed <Assertion> elements as described in [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.).



 TOC 

5.1.4.6.  Service Provider Grants or Denies Access to User Agent

To complete the profile, the service provider processes the <Response> and <Assertion>(s) and grants or denies access to the resource. The service provider MAY establish a security context with the user agent using any session mechanism it chooses, e.g. using [RFC2965] (Kristol, D. and L. Montulli, “HTTP State Management Mechanism,” October 2000.). Any subsequent use of the <Assertion>(s) provided are at the discretion of the service provider and other relying parties, subject to any restrictions on use contained within said assertions.



 TOC 

5.1.5.  Use of Authentication Request Protocol

This profile is based on the Authentication Request protocol defined in [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.). In the nomenclature of actors enumerated in Section 3.4 of that document, the service provider is the request issuer and the relying party, and the principal is the presenter, requested subject, and confirming entity. There may be additional relying parties or confirming entities at the discretion of the identity provider (see below).



 TOC 

5.1.5.1.  <AuthnReq> Usage

A service provider MAY include any message content described in [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.4.1. All processing rules are as defined in [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.). The <Issuer> element MAY be present and if so, it SHOULD contain the unique identifier of the requesting service provider; the Format attribute MUST be omitted or have a value of:

urn:oasis:names:tc:SAML:2.0:nameid-format:entity

If the identity provider cannot or will not satisfy the request, it MUST respond with a <Response> message containing an appropriate error status code or codes.

The identity provider MUST include a <NameIDPolicy> element with the AllowCreate XML attribute set to "true".

The service provider MUST NOT include <Subject> or <Conditions> elements in the request.

Note that if the <AuthnRequest> is not authenticated and/or integrity protected -- i.e. it is not signed -- the parties are taking on certain risks. These are discussed more fully in the Security Considerations section below.



 TOC 

5.1.5.2.  <Response> Usage and Assertion Profile

If the identity provider wishes to return an error, it MUST NOT include an assertion in the <Response> message. Otherwise, if the request is successful -- or if the response is not associated with a request (see Unsolicited Response section) -- the <Response> element, and the <Assertion> it contains, MUST conform to the following:

The <Issuer> element of the <Response> element MAY be omitted, but if present it MUST contain the unique identifier of the issuing identity provider; the Format attribute MUST be omitted or have a value of

urn:oasis:names:tc:SAML:2.0:nameid-format:entity

The <Response> element MUST contain exactly one <Assertion> element. The assertion's <Issuer> element MUST contain an identifier denoting the issuing identity provider; the Format attribute MUST be omitted or have a value of:

urn:oasis:names:tc:SAML:2.0:nameid-format:entity

The assertion MUST contain at least one <AuthnStatement> that reflects the authentication of the principal to the identity provider.

The assertion MUST contain an <AuthnStatement>, which itself MUST contain a <Subject> element with at least one <SubjectConfirmation> element containing a Method of:

urn:oasis:names:tc:SAML:2.0:cm:bearer

The SessionIndex XML attribute MUST NOT be included.

The bearer <SubjectConfirmation> element described above MUST contain a <SubjectConfirmationData> element that contains a Recipient XML attribute containing the service provider's assertion consumer service URL and a NotOnOrAfter XML attribute that limits the window during which the assertion can be delivered. It MAY contain an Address XML attribute limiting the client address from which the assertion can be delivered. It MUST NOT contain a NotBefore XML attribute. If the containing message is in response to an <AuthnRequest>, then the InResponseTo XML attribute MUST match the request's ID.

Other statements and confirmation methods MAY be included in the assertion at the discretion of the identity provider. In particular, <AttributeStatement> elements MAY be included. The <AuthnRequest> MAY contain an AttributeConsumingServiceIndex XML attribute referencing information about desired or required attributes in [OASIS.saml‑metadata‑2.0‑os] (Cantor, S., Moreh, J., Philpott, R., and E. Maler, “Metadata for the Security Assertion Markup Language (SAML) V2.0,” March 2005.). The identity provider MAY ignore this, or send other attributes at its discretion.

The assertion MUST contain an <AudienceRestriction> identifying the service provider in the <Audience>.

Other conditions (and other <Audience> elements) MAY be included as requested by the service provider or at the discretion of the identity provider. Of course, all such conditions SHOULD be understood by and accepted by the service provider in order for the assertion to be considered valid. Though doing so is at the service provider's discretion. The identity provider is NOT obligated to honor the requested set of <Conditions> in the <AuthnRequest>, if any.



 TOC 

5.1.5.3.  <Response> Message Processing Rules

Regardless of the SAML binding used, the service provider MUST do the following:

Verify any signatures present on the assertion(s) or the response.

Verify that the Recipient attribute in any bearer <SubjectConfirmationData> matches the assertion consumer service URL to which the <Response> was delivered.

Verify that the NotOnOrAfter XML attribute in any bearer <SubjectConfirmationData> has not passed, subject to allowable clock skew between the providers.

Verify that the InResponseTo XML attribute in the bearer <SubjectConfirmationData> equals the ID of its original <AuthnRequest> message, unless the response is unsolicited (see Section 5.1.6 (Unsolicited Responses)), in which case the InResponseTo XML attribute MUST NOT be present.

Verify that any assertions relied upon are valid in other respects.

If any bearer <SubjectConfirmationData> includes an Address XML attribute, the service provider MAY check the user agent's client address against it.

Any assertion which is not valid, or whose subject confirmation requirements cannot be met MUST be discarded and MUST NOT be used to establish a security context for the principal.

If an <AuthnStatement> used to establish a security context for the principal contains a SessionNotOnOrAfter XML attribute, the security context SHOULD be discarded once this time is reached, unless the service provider reestablishes the principal's identity by repeating the use of this profile.



 TOC 

5.1.5.4.  POST-specific Processing Rules

The service provider MUST ensure that bearer assertions are not replayed, by maintaining the set of used ID values for the length of time for which the assertion would be considered valid based on the NotOnOrAfter XML attribute in the <SubjectConfirmationData>.



 TOC 

5.1.6.  Unsolicited Responses

An identity provider MAY initiate this profile by delivering an unsolicited <Response> message to a service provider.

An unsolicited <Response> MUST NOT contain an InResponseTo XML attribute, nor should any bearer <SubjectConfirmationData> elements contain one. If metadata as specified in [OASIS.saml‑metadata‑2.0‑os] (Cantor, S., Moreh, J., Philpott, R., and E. Maler, “Metadata for the Security Assertion Markup Language (SAML) V2.0,” March 2005.) is used, the <Response> SHOULD be delivered to the <md:AssertionConsumerService> endpoint of the service provider designated as the default.

Of special mention is that the identity provider MAY include a binding-specific "RelayState" parameter that indicates, based on mutual agreement with the service provider, how to handle subsequent interactions with the user agent. This MAY be the URL of a resource at the service provider. The service provider SHOULD be prepared to handle unsolicited responses by designating a default location to send the user agent subsequent to processing a response successfully.



 TOC 

5.1.7.  Use of Metadata

Please refer to [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) section 4.1.6 for metadata usage guidelines. See also [OASIS.saml‑metadata‑2.0‑os] (Cantor, S., Moreh, J., Philpott, R., and E. Maler, “Metadata for the Security Assertion Markup Language (SAML) V2.0,” March 2005.).



 TOC 

5.2.  Example SAML Assertion

This section presents an example SAML assertion.

In the first example, Figure 2 (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 2: Unsigned SAML Assertion Illustrating Conveyance of Subject Attribute 



 TOC 

5.3.  Security Considerations

This section discusses security considerations this profile's security considerations. The reader should also refer to [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.).



 TOC 

5.3.1.  Unintended Principal Data Leakage

This profile does not require the identity provider to validate the service provider's <AssertionConsumerServiceURL> or <AssertionConsumerServiceInde> as stipulated in the section 4.1.4.1 of the SAMLv2 Web Browser SSO profile specified in [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.).

Additionally, the Lightweight SSO profile specified herein does not require service providers to sign their <AuthnRequest> messages, and thus an identity provider does not, in that case, have cryptographicly-based assurance as to whom it is responding to.

Both of the above items, either together or alone, serve to facilitate arbitrary runtime interactions between identity providers and service providers, however the Principal is vulnerable in these situations to unintended leakage of personal identity information ("PII") to unintended, and perhaps malevolent, parties.



 TOC 

5.3.2.  Man-in-the-middle Attacks and Stolen Assertions

Threat:

Stolen assertion via a MITM

The attacker could then impersonate the subject (the putative caller) at the service provider.
Countermeasures:

SAML's classic approach to this is to have the identity provider sign the assertions. When assertions are integrity-protected and there is data origination authentication, SAML assertion's various content attesting to the issuer, subject, audience, and validity periods serve to reduce risk of a service provider relying upon a replayed assertion.

In this profile however, signing is optional. If the SP accepts unsigned <Response> messages, then it is leaving itself explicitly open to "Man In The Middle" attacks, with all the attendant downsides.



 TOC 

5.3.3.  Forged Assertion

Threat:

A malicious user or user agent could forge or alter a SAML assertion in order to communicate with the service provider since the user agent is used as a conduit.
Countermeasures:

To avoid this kind of attack, the entities must assure that proper mechanisms for protecting the SAML assertion are employed, e.g., signing the SAML <Response> message.



 TOC 

5.4.  Contributors

@@ TODO.



 TOC 

5.5.  Acknowledgments

@@ TODO.



 TOC 

5.6.  IANA Considerations

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



 TOC 

5.7.  Open Issues

None at this time.



 TOC 

5.8.  Change Log

Changes from -00 to -01:

  1. Updated to reference new rev of HTTP POST-SimpleSign Binding.
  2. Minor editorial fixes.



 TOC 

6.  References



 TOC 

6.1. Normative References

[OASIS.saml-bindings-2.0-os] Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Maler, “Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-bindings-2.0-os, March 2005.
[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-metadata-2.0-os] Cantor, S., Moreh, J., Philpott, R., and E. Maler, “Metadata for the Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-metadata-2.0-os, March 2005.
[OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard OASIS.saml-profiles-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.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2392] Levinson, E., “Content-ID and Message-ID Uniform Resource Locators,” RFC 2392, August 1998 (TXT, XML).
[RFC4346] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” RFC 4346, April 2006.
[SSL3] Frier, A., Karlton, P., and P. Kocher, “The SSL 3.0 Protocol,” Netscape Communications Corp. working draft, November 1996.


 TOC 

6.2. Informative References

[IANA.application.samlassertion-xml] OASIS Security Services Technical Committee (SSTC), “application/samlassertion+xml MIME Media Type Registration,” IANA MIME Media Types Registry application/samlassertion+xml, December 2004.
[OASIS.saml-conformance-2.0-os] Mishra, P., Philpott, R., and E. Maler, “Conformance Requirements for the Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-conformance-2.0-os, March 2005.
[OASIS.saml-glossary-2.0-os] Hodges, J., Philpott, R., and E. Maler, “Glossary for the Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-glossary-2.0-os, March 2005.
[OASIS.sstc-saml-exec-overview-2.0-cd-01] Madsen, P. and E. Maler, “SAML V2.0 Executive Overview,” OASIS SSTC Committee Draft sstc-saml-exec-overview-2.0-cd-01, April 2005.
[OASIS.sstc-saml-protocol-ext-thirdparty-cd-02] Cantor, S., “SAML V2.0 Protocol Extension for Third-Party Requests,” OASIS SSTC Committee Draft sstc-saml-protocol-ext-thirdparty-cd-02, September 2006.
[OASIS.sstc-saml-tech-overview-2.0-cd-01] Ragouzis, N., Hughes, J., Philpott, R., Maler, E., Madsen, P., and T. Scavo, “Security Assertion Markup Language (SAML) V2.0 Technical Overview,” OASIS SSTC Committee Draft sstc-saml-tech-overview-2.0-cd-01, March 2007.
[RFC2965] Kristol, D. and L. Montulli, “HTTP State Management Mechanism,” RFC 2965, October 2000 (TXT, HTML, XML).
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, “An IETF URN Sub-namespace for Registered Protocol Parameters,” BCP 73, RFC 3553, June 2003.
[W3C.xmldsig-core] Eastlake, D., Reagle , J., and D. Solo, “XML-Signature Syntax and Processing,” W3C Recommendation xmldsig-core, October 2000.


 TOC 

Authors' Addresses

  Jeff Hodges
  NeuStar
  2000 Broadway Street
  Redwood City, CA 94063
  US
Email:  Jeff.Hodges@neustar.biz
  
  Scott Cantor
  Internet2
  B320-17 KRC-BLDG B -- OSU
  Columbus, OH 43212
  US
Email:  cantor.2@osu.edu


 TOC 

Full Copyright Statement

Intellectual Property

Acknowledgment