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]