None                                                           J. Hodges
Internet-Draft                                                   NeuStar
Intended status: Informational                                 S. Cantor
Expires: April 16, 2007                                        Internet2
                                                        October 13, 2006


               SAMLv2 Lightweight Web Browser SSO Profile
                     draft-hodges-saml-lsso-01.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 April 16, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).













Hodges & Cantor          Expires April 16, 2007                 [Page 1]

Internet-Draft                  SAML-LSSO                   October 2006


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









Hodges & Cantor          Expires April 16, 2007                 [Page 2]

Internet-Draft                  SAML-LSSO                   October 2006


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] 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] and
   [OASIS.sstc-saml-tech-overview-2.0-draft-10] provide non-normative
   overviews of SAMLv2.  The SAMLv2 specification set is normatively
   defined by [OASIS.saml-conformance-2.0-os].





























Hodges & Cantor          Expires April 16, 2007                 [Page 3]

Internet-Draft                  SAML-LSSO                   October 2006


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














































Hodges & Cantor          Expires April 16, 2007                 [Page 4]

Internet-Draft                  SAML-LSSO                   October 2006


3.  Specification Scope

   The scope of this specification is:

   o  Specify a "lightweight" SAML "web browser single sign-on" profile.

   The following are outside the scope of this specification:

   o  Mechanisms for evaluating keys or certificates used for signing.










































Hodges & Cantor          Expires April 16, 2007                 [Page 5]

Internet-Draft                  SAML-LSSO                   October 2006


4.  SAML Introduction

   SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01]
   [OASIS.sstc-saml-tech-overview-2.0-draft-10] 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].

   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:

   o  The SAML assertion must contain at least one authentication
      statement and no other statements.  The relying party must be
      represented in the <AudienceRestriction> element.  The
      SubjectConfirmation Method must be Foo. etc.

   o  The SAML assertion must contain at least one attribute statement
      and may contain more than one.  The values for the subject's
      profile attributes named "Foo" and "Bar" must be present.  An
      authentication statement may be present. etc.

   The primary facets of SAML itself are:




Hodges & Cantor          Expires April 16, 2007                 [Page 6]

Internet-Draft                  SAML-LSSO                   October 2006


   o  Assertions

   o  Abstract Request/Response protocol

   We describe each in turn below:

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.



Hodges & Cantor          Expires April 16, 2007                 [Page 7]

Internet-Draft                  SAML-LSSO                   October 2006


      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.

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




































Hodges & Cantor          Expires April 16, 2007                 [Page 8]

Internet-Draft                  SAML-LSSO                   October 2006


5.  SAML Lightweight SSO Profiles

   This section defines one SAML profile:

      The "Lightweight Web Browser SSO SAML Profile"

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], in conjunction
   with the HTTP POST-SimpleSign binding
   [OASIS.draft-hodges-saml-binding-simplesign-02].

   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.

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].  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], thus
      removing the binding-layer dependency on XMLdsig
      [W3C.xmldsig-core].  Also, this profile does not otherwise
      reference [W3C.xmldsig-core] from the profile itself.

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

         AllowCreate is always "true".

         <Subject> and <Conditions> are disallowed.




Hodges & Cantor          Expires April 16, 2007                 [Page 9]

Internet-Draft                  SAML-LSSO                   October 2006


         Only a single assertion is returned.

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

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

   Identification:

      urn:ietf:params:?:?

      @@ NOTE:  This URN must be agreed upon, and then registered with
         IANA per [RFC3553].

   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.

5.1.3.  Profile Overview

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








Hodges & Cantor          Expires April 16, 2007                [Page 10]

Internet-Draft                  SAML-LSSO                   October 2006


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



Hodges & Cantor          Expires April 16, 2007                [Page 11]

Internet-Draft                  SAML-LSSO                   October 2006


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



































Hodges & Cantor          Expires April 16, 2007                [Page 12]

Internet-Draft                  SAML-LSSO                   October 2006


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

   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.






Hodges & Cantor          Expires April 16, 2007                [Page 13]

Internet-Draft                  SAML-LSSO                   October 2006


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

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.  If initiated by the identity provider,
   start with Section 5.1.4.5.  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.

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.







Hodges & Cantor          Expires April 16, 2007                [Page 14]

Internet-Draft                  SAML-LSSO                   October 2006


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

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]) 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.draft-hodges-saml-binding-simplesign-02].  Profile-specific
   rules for the contents of the <AuthnRequest> message are included in
   Section 5.1.5.1.

   HTTP exchanges in this step SHOULD be made over either TLS [RFC4346]
   or SSL [SSL3] to maintain confidentiality and message integrity.  The
   <AuthnRequest> message SHOULD be signed, using the "SimpleSign
   technique" specified in the binding specification
   [OASIS.draft-hodges-saml-binding-simplesign-02].

   The identity provider MUST process the <AuthnRequest> message as
   described in [OASIS.saml-core-2.0-os].  This may constrain the
   subsequent interactions with the user agent, for example if the
   IsPassive attribute is untilized.

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.



Hodges & Cantor          Expires April 16, 2007                [Page 15]

Internet-Draft                  SAML-LSSO                   October 2006


   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.

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.  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]).  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] to
   maintain confidentiality and message integrity.  The <Response>
   message SHOULD be signed, using the "SimpleSign technique" specified
   in the binding specification
   [OASIS.draft-hodges-saml-binding-simplesign-02].

   The service provider MUST process the <Response> message and any
   enclosed <Assertion> elements as described in
   [OASIS.saml-core-2.0-os].

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





Hodges & Cantor          Expires April 16, 2007                [Page 16]

Internet-Draft                  SAML-LSSO                   October 2006


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

5.1.5.1.  <AuthnReq> Usage

   A service provider MAY include any message content described in
   [OASIS.saml-core-2.0-os], Section 3.4.1.  All processing rules are as
   defined in [OASIS.saml-core-2.0-os].  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.

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



Hodges & Cantor          Expires April 16, 2007                [Page 17]

Internet-Draft                  SAML-LSSO                   October 2006


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



Hodges & Cantor          Expires April 16, 2007                [Page 18]

Internet-Draft                  SAML-LSSO                   October 2006


      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.

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

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



Hodges & Cantor          Expires April 16, 2007                [Page 19]

Internet-Draft                  SAML-LSSO                   October 2006


   NotOnOrAfter XML attribute in the <SubjectConfirmationData>.

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

5.1.7.  Use of Metadata

   Please refer to [OASIS.saml-profiles-2.0-os] section 4.1.6 for
   metadata usage guidelines.  See also [OASIS.saml-metadata-2.0-os].

5.2.  Example SAML Assertion

   This section presents an example SAML assertion.

   In the first example, Figure 2, 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.










Hodges & Cantor          Expires April 16, 2007                [Page 20]

Internet-Draft                  SAML-LSSO                   October 2006


    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

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

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



Hodges & Cantor          Expires April 16, 2007                [Page 21]

Internet-Draft                  SAML-LSSO                   October 2006


   [OASIS.saml-profiles-2.0-os].

   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 Pricipal is vulnerable in these
   situations to unintended leakage of personal identity information
   ("PII") to unintended, and perhaps malevolent, parties.

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.

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



Hodges & Cantor          Expires April 16, 2007                [Page 22]

Internet-Draft                  SAML-LSSO                   October 2006


      signing the SAML <Response> message.

5.4.  Contributors

   @@ TODO.

5.5.  Acknowledgments

   @@ TODO.

5.6.  IANA Considerations

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

5.7.  Open Issues

   None at this time.

5.8.  Change Log

      Changes from -00 to -01:

      1.  Updated to reference new rev of HTTP POST-SimpleSign Binding.

      2.  Minor editorial fixes.

























Hodges & Cantor          Expires April 16, 2007                [Page 23]

Internet-Draft                  SAML-LSSO                   October 2006


6.  References

6.1.  Normative References

   [OASIS.draft-hodges-saml-binding-simplesign-02]
              Hodges, J. and S. Cantor, "SAMLv2: HTTP POST "SimpleSign"
              Binding", OASIS SSTC Working
              Draft draft-hodges-saml-binding-simplesign-02,
              September 2006.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2392]  Levinson, E., "Content-ID and Message-ID Uniform Resource
              Locators", RFC 2392, August 1998.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.



Hodges & Cantor          Expires April 16, 2007                [Page 24]

Internet-Draft                  SAML-LSSO                   October 2006


   [SSL3]     Frier, A., Karlton, P., and P. Kocher, "The SSL 3.0
              Protocol", Netscape Communications Corp. working draft,
              November 1996.

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-01]
              Cantor, S., "SAML Protocol Extension for Third-Party
              Requests", OASIS SSTC Committee Draft sstc-saml-protocol-
              ext-thirdparty-cd-01, March 2006.

   [OASIS.sstc-saml-tech-overview-2.0-draft-10]
              Ragouzis, N., Hughes, J., Philpott, R., and E. Maler,
              "Security Assertion Markup Language (SAML) V2.0 Technical
              Overview", OASIS SSTC Working Draft sstc-saml-tech-
              overview-2.0-draft-10, October 2006.

   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2965, October 2000.

   [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



Hodges & Cantor          Expires April 16, 2007                [Page 25]

Internet-Draft                  SAML-LSSO                   October 2006


              Syntax and Processing", W3C Recommendation xmldsig-core,
              October 2000, <http://www.w3.org/TR/xmldsig-core/>.

















































Hodges & Cantor          Expires April 16, 2007                [Page 26]

Internet-Draft                  SAML-LSSO                   October 2006


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

































Hodges & Cantor          Expires April 16, 2007                [Page 27]

Internet-Draft                  SAML-LSSO                   October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hodges & Cantor          Expires April 16, 2007                [Page 28]