The SAML Standard

SAML is an XML-based standard for communicating authentication, authorization and attribute information amongst online partners. It allows businesses to securely send data regarding the identity and entitlements of a principal between partnered organizations. The Organization for the Advancement of Structured Information Standards (OASIS) Security Services Technical Committee is in charge of defining, enhancing, and maintaining the specifications that define SAML. SAML v2 became an OASIS-approved standard in March, 2005, incorporating the definitions from SAML v1.x with functionality from other standards (including the Liberty ID-FF v1.2 and the Shibboleth initiative). Thus, SAML v2 also takes a critical step towards convergence of many of today's federated identity standards. The SAML v2 specifications can be found on the OASIS web site.

Basic SAML Components

SAML consists of a number of components that, when used together, permit the exchange of identity, authentication, and authorization information between autonomous organizations. The first component is an assertion which defines the structure and content of the information being transferred. The structure is based on the SAML v2 assertion schema. How an assertion is requested by, or pushed to, a service provider is defined as a request/response protocol encoded in its own structural guidelines: the SAML v2 protocol schema. A binding defines the communication protocols (such as HTTP or SOAP) over which the SAML protocol can be transported. Together, these three components create a profile (such as Web Browser Artifact or Web Browser POST). In general, profiles satisfy a particular use case. The following image illustrates how the components are integrated for a SAML interaction.

Figure 1–1 How Basic SAML Components Work Together

Two other components that may be included in SAML messages are:

Metadata

Metadata defines how configuration information shared between two communicating entities is structured. For instance, an entity's support for specific SAML bindings, identifier information, and public key information is defined in the metadata. The structure of the metadata is based on the SAML v2 metadata schema. The location of the metadata is defined by Domain Name Server (DNS) records.

Authentication Context

In some situations, one entity may want additional information to determine the authenticity of, and confidence in, the information being sent in an assertion. Authentication context permits the augmentation of assertions with information pertaining to the method of authentication used by the principal and how secure that method might be. For example, details of a multi-factor authentication can be included.

More general information on SAML can be found at the OASIS web site or in the Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide.

SAML v2 Summary

The SAML v2 specifications are defined more broadly with particular attention paid to functionality dealing with federation. The new specifications clean up and make enhancements to existing functionality as well as integrating features previously defined in the Liberty ID-FF v1.2 and the Shibboleth initiative. Here is a summary of some of the concepts and features of SAML v2.

This is a summary of features defined in the SAML v2 specifications. See Key Features for a list of only those supported in the Sun Java System SAML v2 Plug-in for Federation Services product.

• Contains two concepts (appropriated from the Liberty ID-FF) that were not previously defined in the SAML specifications.

  • An identity provider is the system, or administrative domain, that asserts information about a subject. (It might also be referred to as a SAML authority, authentication authority, attribute authority, or asserting party). The identity provider might attest in a SAML assertion that a user has been authenticated because the user entered certain, associated attributes. For example, user John Doe has an email address of john.doe@acompany.com. The assertion from the identity provider might declare that John Doe was authenticated into the identity provider system by entering an email address and associated password.

  • A service provider is the system, or administrative domain, that relies on information supplied to it by an identity provider. (It might also be referred to as a relying party, or assertion consumer). It is the responsibility of the service provider to decide whether it trusts the identity provider from which SAML assertions are sent. The SAML assertion though does not dictate access; it is local policy that defines whether the subject may access local resources.

• Supports the following bindings for exchanging request/response pairs (protocol messages):

  • HTTP Redirect

  • HTTP POST

  • SOAP

  • HTTP Artifact

    ---

    Caution –

    Previously, only an assertion could be exchanged using HTTP Artifact. Now, any protocol message can be exchanged using the artifact binding although small-sized messages and those that are not crucial (such as logout responses) should still not use it.

    ---

• Supports name identifier encryption (based on the Liberty ID-FF v1.x feature already developed for the Name ID Mapping protocol) and assertion encryption.

• Supports Reverse PAOS Binding in the Enhanced Client and Proxy (ECP) context.

• Supports unsolicited response.

• Allows use of pseudonyms (a key privacy-enabling technology) and name identifier management (for managing pseudonyms).

  ---

  Note –

  Name identifier management encompasses both name registration and federation. These were separate features in the Liberty ID-FF v1.x.

  ---

• Supports an identity provider discovery profile for specifying an identity provider in deployments having more than one.

• Contains a metadata schema (for expressing configuration and trust-related data).

• Supports encryption of attribute statements, name identifiers, or entire assertions.

• Supports session management for single logout.

• Support for mobile standards.

• Supports affiliations.

• Supports the Transient Name Identifier Format

• Contains new attributes in the Name Identifier Policy, Identity Provider Proxying and Name Identifier Mapping protocols.