SAML 2.0

SAML 2.0 enables web-based, cross-domain single sign-on (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to the user.

The critical aspects of SAML 2.0 are covered in detail in the official documents SAMLCore,[1] SAMLBind,[2] SAMLProf,[3] and SAMLMeta.

An assertion is a package of information that supplies zero or more statements made by a SAML authority.

Note that in the above example the element contains the following child elements: In words, the assertion encodes the following information: The assertion ("b07b804c-7c29-ea16-7300-4f3d6f7928ac") was issued at time "2004-12-05T09:22:05Z" by identity provider (https://idp.example.org/SAML2) regarding subject (3f7b3dcf-1674-4ecd-92c8-1544f346baf8) exclusively for service provider (https://sp.example.com/SAML2).The authentication statement, in particular, asserts the following: The principal identified in the element was authenticated at time "2004-12-05T09:22:00Z" by means of a password sent over a protected channel.Likewise the attribute statement asserts that: The principal identified in the element has the 'staff' and 'member' attributes at this institution.The following protocols are specified in SAMLCore:[1] The most important of these protocols—the Authentication Request Protocol—is discussed in detail below.

When a principal (or an entity acting on the principal's behalf) wishes to obtain an assertion containing an authentication statement, a element is transmitted to the identity provider: The above element, which implicitly requests an assertion containing an authentication statement, was evidently issued by a service provider (https://sp.example.com/SAML2) and subsequently presented to the identity provider (via the browser).

SAML protocol messages can be carried directly in the URL query string of an HTTP GET request.

SAML requests or responses transmitted via HTTP Redirect have a SAMLRequest or SAMLResponse query string parameter, respectively.

When the contains information not known by the IdP beforehand, such as Assertion Consumer Service URL, signing the request is recommended for security purposes.

Initially, the service provider responds to a request from the user agent with a document containing an XHTML form: The value of the SAMLRequest parameter is the base64-encoding of a element, which is transmitted to the identity provider via the browser.

The SSO service at the identity provider validates the request and responds with a document containing another XHTML form: The value of the SAMLResponse parameter is the base64 encoding of a element, which likewise is transmitted to the service provider via the browser.

Finally, the service provider returns a element containing the referenced message: Of course the flow can go in the other direction as well, that is, the identity provider may issue an artifact, and in fact this is more common.

The MessageHandle is a random sequence of bytes that references a SAML message that the artifact issuer is willing to produce on-demand.

The identity provider returns the SAML Response to the SP Assertion Consumer Service using the HTTP-POST Binding.

The RelayState token is an opaque reference to state information maintained at the service provider.

The SSO Service at the identity provider processes the element (by URL-decoding, base64-decoding and inflating the request, in that order) and performs a security check.

Respond with an XHTML form The service provider responds with a document containing an XHTML form: The RelayState token is an opaque reference to state information maintained at the service provider.

Request the SSO Service at the IdP The user agent issues a POST request to the SSO service at the identity provider: where the values of the SAMLRequest and RelayState parameters are taken from the XHTML form at step 2.

The SSO service processes the element (by URL-decoding, base64-decoding and inflating the request, in that order) and performs a security check.

For each browser user, this cookie stores a history list of recently visited IdPs.

The name and value of the cookie are specified in the IdP Discovery Profile (SAMLProf[3]).

After a successful act of authentication, the IdP requests the Common Domain Cookie Writing Service.

Below we give an example of a query issued by a principal directly: Note that the Issuer is the Subject in this case.

An identity provider might return the following assertion, wrapped in a element (not shown): In contrast to the BearerAssertion shown earlier, this assertion has a longer lifetime corresponding to the lifetime of the X.509 certificate that the principal used to authenticate to the identity provider.

SAML 2.0 provides a well-defined, interoperable metadata format that entities can leverage to bootstrap the trust process.

An identity provider publishes data about itself in an element: Note the following details about this entity descriptor: By definition, an identity provider manages an SSO service that supports the SAML Web Browser SSO profile specified in SAMLProf.

[3] See, for example, the identity provider described in the element shown in the next section.

Note the following details about this element: As noted at the beginning of this section, the values of the Location attributes are used by a service provider to route SAML messages, which minimizes the possibility of a rogue identity provider orchestrating a man-in-the-middle attack.

[3] See, for example, the service provider described in the element shown in the next section.

The assertion consumer service is contained in an element: Note the following details about the metadata element: As noted at the beginning of this section, the values of the Location attributes are used by an identity provider to route SAML messages, which minimizes the possibility of a rogue service provider orchestrating a man-in-the-middle attack.

In practice, however, multiple elements are grouped together under an element with a single digital signature over the entire aggregate: Note the following details about the above element: Typically metadata aggregates are published by trusted third parties called federations who vouch for the integrity of all the metadata in the aggregate.