Download document
| Federations.org Draft | A. Solberg |
| UNINETT | |
| E. Maler | |
| Sun Microsystems | |
| S. Cantor | |
| Ohio State University | |
| L. Johansson | |
| Stockholm University | |
| June 2008 |
Interoperable SAML 2.0 Web Browser SSO Deployment Profile
saml2simplified
Abstract
$Id: saml2simplified.xml 24 2008-06-19 20:46:42Z andreas $
This deployment profile of SAML 2.0 Single Sign-On (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.
1
Requirements notation
2
Introduction
2.1
Interoperability
2.2
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
§
Non-Normative 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 Single Sign-On (SSO) 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 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.
3 Single Sign-On Profile
This deployment profile of SAML 2.0 Single Sign-On (SSO) defines a minimal 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 Identity Provider is not required to validate possible signatures on an incoming <samlp:AuthnRequest>.
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 amitted.
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>, and that URL must exactly match one of the <samlmd:AssertionConsumerURL>s specified in the Service Provider's metadata.
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]. The public key corresponding to the private key used to sign the <samlp:Response> MUST be embedded in the Identity Provider's metadata as a KeyDescriptor with @usage="signing".
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 Service Provider MUST interpret a SubjectConfirmation@Method with a value of urn:oasis:names:tc:SAML:2.0:cm:bearer, but is not required to understand any other methods.
The assertion MUST contain <saml:Subject> and the <saml:Subject> MUST contain a <saml:NameID> and a <saml:SubjectConfirmation> element. The SubjectConfirmation@Method MUST be set to urn:oasis:names:tc:SAML:2.0:cm:bearer.
The Identity Provider MUST include a <saml:NameID> in the Response. 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 Service Provider MUST be able to verify the following attributes of <saml:SubjectConfirmation>:
- NotOnOrAfter
- Recipient
The SubjectConfirmationData@NotOnOrAfter attribute, if set, will impact the maximum session duration the Service Provider is allowed to establish with the user.
If the Identity Provider would like to enforce any additional SubjectConfirmationData attributes, it will need to establish an explicit agreement with the Service Provider to ensure the confirmation requirements are enforced. This agreement could be in form of a complimentary profile.
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). If the Service Provider provides a public key in its metadata, it MUST be capable of decrypting Assertions.
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
A Service Provider indicates support for Single Log-Out by including a SingleLogoutService endpoint in its SAML 2.0 Metadata.
This profile does not require entities to support the Single Log-Out profile. A given deployment environment could require this in a complimentary profile specification.
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>.
| [saml2-core] | OASIS, "SAML 2.0 Core". |
| [saml2-bindings] | OASIS, "SAML 2.0 Bindings". |
| [saml2-profiles] | OASIS, "SAML 2.0 Profiles". |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. |
| [MACE] | MACE, "MACE: Attribute schemes". |
Author's Addresses
| Andreas Åkre Solberg | |
| UNINETT | |
| Phone: | +47 41 10 77 00 |
| EMail: | andreas.solberg@uninett.no |
| URI: | http://rnd.feide.no |
| Eve Maler | |
| Sun Microsystems | |
| EMail: | eve.maler@sun.com |
| Scott Cantor | |
| Ohio State University | |
| EMail: | cantor.2@osu.edu |
| Leif Johansson | |
| Stockholm University | |
| EMail: | leifj@it.su.se |
Great Work, Andreas!
I've been meaning to do this myself, but now I don't have to :-) Here are a couple of suggestions:
1. EntityID MUST be a URL. The URL protocol SHOULD be https.
2. Entities MUST provide metadata at their EntityID URL. Metadata SHOULD be signed.
I think these would greatly help deployment of SAML 2.0. Credit to PingID for suggesting this in their Dynamic SAML work.
Also, there's a neat trick to aid robustness of SLO - render a page with an iframe for each provider. ADFS does this for WS-Federation SLO and it works well. You could set a timer in the page to redirect the browser after a reasonable length of time. In any case, this is an implementation detail and does not affect the wire protocol.