SAML 2.0 simplifies federation

Until this year, identity federation has suffered from the problem of too many standards. Companies that deployed federation before the fourth quarter were forced to deal with five incompatible protocols: OASIS Security Assertion Markup Language 1.0 and 1.1, Liberty Alliance ID-FF 1.1 and 1.2 and Shibboleth. The result was a complex matrix of enterprise and consumer use cases, protocols and implementations that slowed the growth and increased the cost of federation deployments.

The Organization for the Advancement of Structured Information Standards (OASIS), the Liberty Alliance and Shibboleth have since joined forces to create a single standard that would make their previous work obsolete. The result is SAML 2.0, which OASIS ratified in March and is beginning to appear in vendor products. SAML 2.0 radically alters the federation landscape by removing the largest barrier to increased federation adoption: multiprotocol complexity.

OASIS, Liberty and Shibboleth originally came at federation from three perspectives: OASIS SAML focused primarily on business-to-business interactions (single sign-on between enterprises), Liberty focused on consumer (business-to-consumer) interactions requiring privacy, and Shibboleth focused on educational environments requiring anonymity. Hence, they modified and extended the original SAML 1.0 specification to support different uses. These federation protocols are not interoperable or backward-compatible.

Before SAML 2.0, organizations looking to deploy federated identity had to negotiate protocol selection with each federation partner. Many had to support multiple protocols through protocol mapping and translation techniques that cause support gaps for key features or capabilities.

SAML 2.0 incorporates every critical-use case and feature from every predecessor protocol into a single standard. As it represents a superset of all the functionality in all five predecessors, SAML 2.0 makes them obsolete.

SAML 2.0 describes two roles for enabling federation; the service provider is the entity that makes an application or resource available to the user, while the identity provider is responsible for authenticating the user. The service provider and the identity provider exchange messages to enable single sign-on and single log-out. These message exchanges can be initiated by the identity provider or the service provider.

For single sign-on, the identity provider is responsible for creating a SAML assertion that contains the identity of a user and then securely sends that assertion to the service provider. The service provider is responsible for validating the SAML assertion before letting the user access the application.

A SAML assertion is an XML document that contains many statements pertaining to the identity of the user. These statements include information about how a user was authenticated and, optionally, additional user attributes.

This exchange of messages can occur via different SAML bindings, such as using an HTTP form Post via the browser, or a Simple Object Application Protocol back-channel interaction.