Interoperable SAML 2.0 Web Browser SSO Deployment Profile
saml2simplified

Abstract

$Id: saml2simplified.xml 31 2008-06-20 10:32:48Z andreas $

[ View all revisions ]

This deployment profile of SAML 2.0 Web Browser SSO defines a minimal set of requirements that entities need to support in order to be interoperable.

Service Providers and Identity Providers implementing this profile may interoperate with other entities implementing the same profile, as well as with entities that honour the conformance guidelines of Liberty Alliance for SP, SP-Lite, IdP and IdP-Lite.

Table of Contents

1  Requirements notation
2  Introduction
 2.1  Interoperability
 2.2  Specification Scope
 2.3  References to SAML 2.0 specification
3  Single Sign-On Profile
 3.1  The AuthnRequest
 3.2  The Response
  3.2.1  The Assertion
  3.2.2  Encryption of the Response
4  Single Log-Out Profile
5  Security Considerations
§  Normative References
§  Informative References
§  Author's Addresses

1  Requirements notation

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

2  Introduction

This deployment profile of SAML 2.0 Web Browser SSO (and optionally Log-Out) defines a minimal set of requirements that entities need to support in order to be interoperable. The goals of this profile include:

• Easy implementation that can be based on available SAML libraries.
• Good support in current available SAML 2.0 software implementations
• Minimal effort required to configure entities to support this profile from a default installation.
• Increased interoperability between SAML 2.0 implementations and deployment environments, thanks to a very limited set of required options.

This profile draws upon operational experience of several SAML-based federations in the higher-education and research community and reflects best current practice of a wide range of deployments involving web single sign-on. The authors believe that this profile has broad applicability outside the scope of education and research.

2.1  Interoperability

One of the main goals of this profile is to increase interoperability between deployments, as well as across SAML 2.0 implementations.

Service Providers and Identity Providers implementing this profile may interoperate with other entities implementing the same profile.

2.2  Specification Scope

The scope of this specification is:

• A SAML 2.0 deployment profile, "Single Sign-On Profile", that limits the options available in SAML 2.0 SSO to increase interoperability between deployments.
• An optional SAML 2.0 deployment "Single Log-Out Profile".

2.3  References to SAML 2.0 specification

When referring to elements from the SAML 2.0 core specification [saml2-core], the following syntax is used:

• <samlp:Protocolelement> - for elements from the SAML 2.0 Protocol namespace.
• <saml:Assertionelement> - for elements from the SAML 2.0 Assertion namespace.

This profile is a normative deployment profile for the SAML 2.0 Web Browser SSO Profile (urn:oasis:names:tc:SAML:2.0:profiles:SSO:browser), as specified in [saml2-profiles]. Text from [saml2-profiles], [saml2-core] and [saml2-bindings] is background material, and is not repeated in this document.

All entities supporting this profile MUST provide SAML 2.0 Metadata following the Interoperable SAML 2.0 Metadata Profile [saml2-metadata-profile] specification.

3  Single Sign-On Profile

This deployment profile of SAML 2.0 Single Sign-On (SSO) defines a set of requirements that entities need to support in order to be interoperable with other entities.

3.1  The AuthnRequest

The <samlp:AuthnRequest> issued by the Service Provider MUST be sent to the Identity Provider using the HTTP-REDIRECT binding.

The Service Provider SHOULD NOT sign the <samlp:AuthnRequest>. If the Service Provider is siging the request, it MUST NOT assume that the Identity Provider is validating the signature unless an explicit agreement is made about doing so.

As this profile only allows the HTTP-POST binding for the <samlp:Response>, the <samlp:AuthnRequest> MUST either have the @ProtocolBinding attribute to be set to urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST, or omitted.

The Identity Provider MUST interpret @ForceAuthN="True", and return a SAML Error if forced re-authentication is not supported. If the Identity Provider returns a SAML Response with Success, the Service Provider can safely assume the Identity Provider session was re-authenticated.

The Identity Provider MUST interpret IsPassive="True", and return an SAML Error if it does not support the passive behaviour.

The <samlp:AuthnRequest> MUST contain an <samlmd:AssertionConsumerURL>.

To increase the chance of interoperability the <samlp:AuthnRequest> SHOULD NOT include a <samlp:RequestedAuthnContext> element. The support for different authetication context classes, and the semantics around the different classes may be interpreted differently and may potentially cause interoperability problems. If the <samlp:RequestedAuthnContext> is included in the request, the participating entities SHOULD have a already established agreement upon which authentication context classes that are available.

The NameIDPolicy SHOULD be included in the <samlp:AuthnRequest> and be set to True.

If the Service Provider includes a NameIDPolicy@Format in the <samlp:AuthnRequest>, it SHOULD be set to either of

• urn:oasis:names:tc:SAML:2.0:nameid-format:transient
• urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

The Identity Provider MUST support the transient NameID format.

3.2  The Response

The Service Provider MUST support both unsolicited responses and responses mapped to an <samlp:AuthnRequest>.

The Response MUST be sent using the HTTP-POST binding [saml2-bindings].

3.2.1  The Assertion

If successfull, the <samlp:Response> MUST contain one <saml:Assertion>. The Assertion MUST contain one <saml:AuthnStatement> and zero or one <saml:AttributeStatement>. The <saml:AttributeStatement> MAY contain any number of <saml:Attribute>-s, which may be multi-valued.

The assertion MUST contain a <saml:Subject> and the <saml:Subject> MUST contain a <saml:NameID>.

If the <samlp:AuthnRequest> included a NameIDPolicy@NameIDFormat, the NameID@Format in the response MUST match. If the request did not include a NameIDPolicy@NameIDFormat the NameID@Format in the response MUST be either of:

• urn:oasis:names:tc:SAML:2.0:nameid-format:transient
• urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

The <saml:Authnstatement> SHOULD NOT include a <saml:NameID>, and if a <saml:NameID> is included it MUST be identical to the one in the parent <saml:Assertion> element.

The Identity Provider MUST include a <saml:Conditions> element. Conditions restricting the period when the assertion is valid, the @NotBefore and @NotOnOrAfter MUST be included.

The Identity Provider SHOULD NOT assume that the Service Provider can interpret any other Attribute@NameFormat than urn:oasis:names:tc:SAML:2.0:attrname-format:uri.

For higher education, attribute schemes are standarized by [MACE].

Encoding attribute values as plain strings is strongly RECOMMENDED. Past experience has shown that using simple strings eases interoperation between different products compared to other encoding methods.

3.2.2  Encryption of the Response

The content of the Assertion MUST be protected against eavesdropping, either by encrypting the assertion, or by ensuring that the response is sent on a secure transport.

The Service Provider MUST either support decrypting <saml:EncryptedAssertions>, or the AssertionConsumerService endpoint MUST use a secure transport connection (SSL/HTTPS).

The Identity Provider MUST NOT send an unencrypted Assertion to an unprotected (HTTP) AssertionConsumerService endpoint, or present the <form> containing the response on an unprotected (HTTP) XHTML/HTML page.

4  Single Log-Out Profile

An entity MAY support Single Log-Out. If the entity supports Single Log-Out, it MUST follow the requirements in this section.

All Service Providers that support Single Log-Out MUST both be able to initiate a logout, send a <samlp:LogoutRequest> to the IdP, as well as handle an incoming <samlp:LogoutRequest> from the Identity Provider.

When the Service Provider initiates a logout, it MUST first set the local session to an unauthenticated state, and then send a <samlp:LogoutRequest> message to the Identity Provider using the HTTP-REDIRECT binding [saml2-bindings]. The <samlp:LogoutRequest> MUST include both a <saml:NameID> and a <saml:SessionIndex>.

The Identity Provider does not have to be able to initate logouts unless it provides the user with some way of doing local login at the Identity Provider. When the Identity Provider retrieves an <samlp:LogoutRequest> it MUST first mark its own session with the user in an unauthenticated state. Thereafter it MUST issue an <samlp:LogoutRequest> to all other logged in SPs, as specified in [saml2-profiles]. These requests MUST include both <saml:NameID> and <saml:SessionIndex>.

5  Security Considerations

As this profile does not require validation of signed authentication request messages, the Service Provider cannot assume that the content of the request has not been tampered with. Consequences of this include:

• If the Service Provider included a <saml:RequestedAuthnContext> element in the request, it cannot rely on the Identity Provider to honor the requirements. It should only consider the required authentication context as guidance, and instead verify the <saml:AuthnContext> provided in the <samlp:Response>. This approach also makes it easier to support unsolicited responses.
• If the Service Provider requires the user to present a fresh authentication, and sends a request with ForceAuthn="True", the Identity Provider needs a way of including information in the <samlp:Response> that a fresh authentication has been performed. It is recommended to include such information in the <samlp:Response>, although there is no dedicated field for this information. One way of providing this information could be for the Service Provider and the Identity Provider to agree upon an attribute for this information.

This profile does not allow an authentication response to be sent unencrypted over the network. Either the <saml:Assertion> is encrypted end-to-end, or all endpoints are required to use encrypted transport. When the <saml:Assertion> is not encrypted, the content will be exposed in the user's web-browser. The content cannot be tampered with by the user, because the message is signed. However, the user may be able to decode and view attributes sent in the <samlp:Response>.

Normative References

Informative References

Author's Addresses