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.