3 SAML 1.1 Authentication Request and Response Profiles

The ability of federation members to interoperate with other federation members depends both on the software deployed and on the protocols and profiles which they use for communication. This section describes the profiles recommended for use within the federation.

Profiles for SAML 2.0

As well as the original SAML 1.1 standard, many SAML implementations now support the more modern SAML 2.0. Indeed, some more recent implementations have minimal or even no support for the older protocol.

Technical implementation and deployment profiles for SAML 2.0 operation within the UK federation can be found in [UKFTS]. Future editions of this document will include additional recommendations for the use of SAML 2.0.

For maximum compatibility, we recommend that all new deployments are made using software capable of both SAML 1.1 and SAML 2.0 operation. We believe that these protocols will exist in parallel for the foreseeable future.

The only authentication request profile currently recommended for use with SAML 1.1 within the UK federation is the Shibboleth authentication request profile (urn:mace:shibboleth:1.0:profiles:AuthnRequest) as described in section 3.1.1 of [ShibProt].

All current federation SAML 1.1 identity providers implement this profile. The centralised “Where Are You From” (WAYF) discovery service provided by the UK federation also operates on the basis of this profile.

3.2.1 SAML 1.1 Browser/POST With Attribute Pull

This profile is defined in [SAMLBind] section 4.1.2; its use in Shibboleth is as described in [ShibProt] section 3.1.2.

We strongly recommend that all new members of the UK federation deploy software capable of making use of the SAML 1.1 Browser/POST profile, as this is the only authentication response profile known to be supported by all current federation entities supporting SAML 1.1.

Identity providers should always implement SAML 1.1 Browser/POST with attribute pull, which is to say in such a way that the authentication assertion is sent to the service provider without any accompanying attributes. This then causes the service provider to issue a separate attribute request over a protected and mutually authenticated channel, so that the transfer of attributes is both secure and known to be at the request of a particular identified party. This attribute exchange profile is described in [ShibProt] section 3.2.

During the attribute exchange operation, the service provider has the opportunity to indicate the attributes it is requesting through the use of the AttributeDesignator element. The Shibboleth service provider software can be configured to make use of this facility using corresponding AttributeDesignator elements in its configuration file. Note, however, that this is not the default configuration and many service providers therefore omit the AttributeDesignator element from their queries; such a query becomes a request for all attributes whose release is permitted by the identity provider’s attribute release policy for that service provider.

An identity provider is always responsible for protecting the privacy of its users through its choice of the attributes to be released to a particular service provider. Identity providers should never attempt to delegate that responsibility by relying on appropriate AttributeDesignator elements being expressed by a service provider. Instead, identity providers should define appropriate attribute release policies for each service provider to which attributes containing personal data need to be released. The default attribute release policy should only allow the release of privacy preserving attributes.

We strongly recommend that SAML 1.1 Browser/POST is never implemented with attribute push, which causes the attributes for the subject to accompany the authentication assertion.

This method of operation is insecure, as it transports the attributes in an unencrypted fashion through the user’s browser. This makes possible attacks based on impersonating the service provider’s identity, either through weaknesses in the browser’s PKIX implementation, or through tricking the user in so-called “phishing” attacks. The attribute pull mechanism is not vulnerable to these particular attacks.

3.2.2 SAML 1.1 Browser/Artifact With Attribute Push

The Browser/Artifact profile is defined in [SAMLBind] section 4.1.1; its use in Shibboleth is described in [ShibProt] section 3.1.3.

The advantages of the Browser/Artifact profile include faster authentication speed in certain circumstances, and a removal of the Browser/POST profile’s need for ECMAScript support in the user’s browser. Against this must be weighed the lack of widespread support for this profile by current federation members.

Browser/Artifact can be deployed with either attribute push or attribute pull without loss of security. However, Browser/Artifact with attribute pull causes two communications to be made back to the identity provider after the authentication assertion has been sent to the service provider, and is therefore much slower. We recommend the use of attribute push whenever the Browser/Artifact profile is employed.

An identity provider is always responsible for protecting the privacy of its users through its choice of the attributes to be released to a particular service provider. When using attribute push, an identity provider always releases all attributes included in the attribute release policy for the particular service provider. Therefore, identity providers should define appropriate attribute release policies for each service provider to which attributes containing personal data need to be released. The default attribute release policy should only allow the release of anonymous attributes.

We recommend deploying the Browser/Artifact profile if the software you are using supports it.

We do not recommend deploying entities capable of supporting only the Browser/Artifact profile.

Prevalence of SAML 1.1 Browser/Artifact

At the time of writing, the SAML 1.1 Browser/Artifact profile is supported by around 95% of all identity providers that support SAML 1.1. However, the recommendation that all SAML 1.1 entities remain capable of handling the SAML 1.1 Browser/POST profile is likely to stand for the foreseeable future, as it is unlikely that SAML 1.1 Browser/Artifact will ever be supported by every entity.

3.2.3 Choice of Authentication Response Profile by Service Providers

The Shibboleth authentication request profile requires the service provider sending the authentication request to include the location of an assertion consumer service in the request. This location must match one of the AssertionConsumerService elements described in the federation metadata for that service provider, and each such element also includes a Uniform Resource Identifier (URI) specifying the profile bound to that location.

If a service provider performs discovery locally, so that it knows the identity provider to which it is sending the authentication request, it may nominate any of its assertion consumer service locations that supports a profile known to be supported by that identity provider.

If the service provider does not perform local discovery, and instead makes use of centralised discovery services provided by the federation’s WAYF, it must nominate an assertion consumer service location without advance knowledge of the identity provider which the request will be sent to. As not all federation identity providers currently support the Browser/Artifact profile, but all do support the Browser/POST profile, the service provider must always select the Browser/POST profile in this case.