SAML 2: The Building Blocks of Federated Identity
For some, nothing beats the adventure of setting off on a trip to some faraway land carrying nothing but a toothbrush and a guidebook. Traveling to some remote locale and bringing little of the comforts of home is what makes it interesting and rewarding–no Holiday Inn for these hardy souls. For the rest of us, however, an enjoyable trip is one in which we are able to experience the different sights and sounds of the destination whilst bringing with us (baggage restrictions allowing) some subset of those comforts that we associate with home. Our experience at our destination can be more rewarding and less taxing if we do not arrive empty-handed, rather bringing with us that which we can use to personalize and customize the otherwise strange destination–even if nothing more than pictures of loved ones and your favorite herbal tea.
So it is with online "travel." If, as we surf to different sites, we can carry with us from "home" relevant information to present to the visited site, our experience there can be far less fatiguing and strange. Rather than stuffing tea bags and snapshots in our luggage, when online, we bring with us appropriate views of the data that defines us online–our digital identity.
To make this possible, this identity information (e.g. who we are, what we are, where we are, etc) must be portable from one site to another, implying both standardized syntaxes by which it can be expressed and protocols by which it can be communicated. While there are existing mechanisms for passing such identity (e.g., inter-enterprise directory services, data synchronization, and delegated administration), these mechanisms have shown themselves to be either labor-intensive or expensive or both–especially as the number of business relationships any one enterprise must manage grows.
Similar to the motivation for web services in application integration, there is a need for loosely coupled mechanisms for identity management integration. The Security Assertions Markup Language (SAML) is a standard that enables such loosely coupled and federated identity integration. SAML standardizes how identity-related security information can be communicated between policy domains; as such, SAML is a key underpinning for federated identity because it provides a standardized security infrastructure upon which other aspects of federated identity (e.g., permissions-based attribute sharing) can be built.
Version 2 of SAML will soon be ratified as an Organization for Advancement of Structured Information Sciences (OASIS) standard. This article provides an overview of SAML 2.0, highlighting why this version is so important to federated identity.
What Is SAML?
SAML defines an XML-based framework for communicating security and identity (e.g., authentication, entitlements, and attribute) information between computing entities. SAML promotes interoperability between disparate security systems, providing the framework for secure e-business transactions across company boundaries. By abstracting away from the particulars of different security infrastructures (e.g., PKI, Kerberos, LDAP, etc), SAML makes possible the dynamic integration necessary in today's constantly changing business environments.
What Isn't SAML?
SAML does not standardize all aspects of identity management. SAML addresses one key aspect of identity management, namely that of how identity information can be communicated from one domain to another. A full identity management solution will also define mechanisms for, amongst other aspects, provisioning (the establishment and subsequent management of accounts and associated privileges), authentication (how an entity proves their right to lay claim to a particular identity), or access control (how the rules for specifying what individual identities are allowed to do are captured). SAML has been designed to be compatible with existing and emerging standards that address these other aspects.
Why Is SAML Important?
Standards for federated identity are critical since proprietary mechanisms for distributed identity management means companies must build one-off links for each business partner they wish to do business with. SAML's benefits include:
Platform neutrality –SAML abstracts the security framework away from particular vendor implementations and architectures.
Loose coupling–SAML does not require user information to be maintained and synchronized between directories.
Improved Online Experience for end-users–SAML authentication assertions enables single sign-on by allowing users to authenticate at an identity provider and then access services/resources at service providers without additional authentication. Alternatively, SAML attribute assertions can enable a similar end-user experience while supporting anonymity.
What Is SAML's History?
SAML 1.0 became an OASIS standard in November 2002, SAML 1.1 followed in September 2003. SAML has seen significant success within industry--seeing successful deployments in financial services, higher education, government, and other verticals. SAML has been broadly implemented by all major web access management vendors. SAML is also supported in major application server products, and SAML support is also common among web services management and security vendors.
SAML was designed to be used within other standards--the Liberty Alliance Project, the Shibboleth project, and the OASIS Web Services Security standard have all adopted SAML as a technological underpinning to varying degrees.
What Is Special about SAML 2.0?
SAML 2.0 is a major revision of SAML 1.1 and provides significant additional functionality. Worth noting are the following aspects:
SAML 2.0 unifies the previous disparate federated identity building blocks of SAML 1.1 with input from both higher education's Shibboleth initiative and Liberty's Identity Federation Framework (Liberty ID-FF). As such, SAML 2.0 is a critical step towards full convergence for federated identity standards. The following diagram demonstrates the relationship between the OASIS SSTC and Liberty Alliance specification sets.
Figure 1--Relationship between SAML and ID-FF
Liberty initially defined ID-FF as an extension of SAML 1.0 (and later SAML 1.1). These extensions have now been contributed back into SAML 2.0. Going forward, SAML 2.0 will be the basis on which Liberty builds additional federated identity applications (such as web service-enabled permissions-based attribute sharing).
Federated Identifier Management
While SAML 1.0 and SAML 1.1 defined how Single Sign-On can occur through the communication of an AuthenticationStatement carrying some identifier for a user, the mechanism by which the two sites might agree on the identifier to use for a particular user was not specified. The assumption was that this identifier, be it an email address, social security number, or some meaningless random string, would be agreed upon through some out of band exchange. SAML 2.0 remedies this by defining how two sites can, with the participation of the user, establish an (or multiple) identifier for that user in a dynamic online fashion. SAML 2.0 also defines mechanisms to allow both sites to manage (e.g., update, cancel) identifiers once agreed upon.
Previous versions of SAML were not optimized for privacy. SAML 2.0 has a number of features that support deployments in which privacy is a requirement. Most notably is the definition of the format of a pseudonymous identifier by which two providers can refer to individual principals. Such an opaque string protects the privacy of the principal because it inhibits collusion between multiple providers (as is possible with a global identifier such as an email address).
SAML 2.0 adds support for 'Single Logout', i.e. the ability for the various different sessions established at different sites to be automatically terminated. For instance, if a user, after authenticating to a SAML authority, established sessions at multiple other sites through the single sign-on mechanism and if the user was to log-out of any one of these sessions, it could result in all the other sessions being terminated as well (this determined both by the user's preferences and the policies of the various sites).
What Are the Components of SAML 2.0?
An assertion is a package of information that supplies one or more statements made by a SAML authority. SAML defines three different kinds of assertion statement that can be made by a SAML authority.
Authentication: The specified subject was authenticated by a particular means at a particular time.
Attribute: The specified subject is associated with the supplied attributes.
Authorization Decision: A request to allow the specified subject to access the specified resource has been granted or denied.
The following example demonstrates a SAML 2.0 Authentication Statement and highlights some of the differences from SAML 1.1.
1 <saml:Assertion 2 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 3 Version="2.0" 4 IssueInstant="2005-04-01T16:58:33.173Z"> 5 <saml:Issuer>http://authority.example.com/</saml:Issuer> 3 <!-- signature by the issuer over the assertion --> 6 <ds:Signature>...</ds:Signature> 7 <saml:Subject> 8 <saml:NameID format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"> 9 jygH5F90l 10 </saml:NameID> 11 </saml:Subject> 12 <saml:AuthnStatement 12 AuthnInstant="2005-04-01T16:57:30.000Z" 13 SessionIndex="6345789"> 14 <saml:AuthnContext> 15 <saml:AuthnContextClassRef> 16 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 17 </saml:AuthnContextClassRef> 18 </saml:AuthnContext> 19 </saml:AuthnStatement> 20 </saml:Assertion>
Whereas in SAML 1.1 the
Subject was located within the
AuthnStatement element, in SAML 2.0 it has been promoted up a level (lines 7 through 11) such that it is a child of the
Assertion itself. This allows a SAML authority to more easily make multiple statements (e.g., an authentication statement indicating that a user had logged in as well as an attribute statement attesting to their role within an enterprise) about the same subject of an assertion. The new
SessionIndex (line 13) indexes a particular session that the user may have established with the SAML authority such that differentiated management (e.g., log out) can be applied to multiple such sessions. The
AuthenticationContext element (lines 14 through 19) replaces the SAML 1.1 AuthenticationMethod attribute and provides a more flexible mechanism by which the SAML authority can describe how the user authenticated in addition to the fact that they did. In this case, the URI on line 16 indicates that the user authenticated to the authority by presenting a password over SSL.
SAML defines a number of different (generally) request and response protocols, by which an entity can interact with a SAML authority to:
Retrieve one or more existing assertions from an authority (either specifying a particular assertion or specifying criteria against which potential assertions should be filtered)
Request that a principal be authenticated and the corresponding authentication statement be returned
Request that the authority use a specified name identifier for the principal in question in subsequent interactions
Retrieve an existing protocol message by means of an artifact that represents that protocol message. The artifact mechanism allows assertions to be effectively communicated over bandwidth-constrained channels.
Request a near-simultaneous logout of a collection of related sessions (“single logout”)
- Request a name identifier be mapped into the appropriate name identifier usable at a 3rd provider
When a SAML authority receives one of the above requests, it will reply with a response message. Unless there was a problem (e.g. an improperly formatted request or unauthorized requestor), the response will include an assertion element containing the appropriate type of statement.
The SAML protocols are defined in the abstract--the mappings of these abstract message exchanges into real-world messaging or communication protocols are called SAML protocol bindings. For instance, the SAML SOAP Binding defines how SAML protocol messages can be communicated within SOAP messages whilst the SAML URI Binding defines how SAML protocol messages can be communicated through URI resolution.
The core SAML specification provides significant flexibility with respect to how a particular message might be assembled. While this flexibility is appropriate for such a multi-purpose framework as SAML, it is not conducive to interoperability. The SAML profiles address this issue. Generally, a profile of SAML defines constraints and/or extensions of the core protocols and assertions in support of the usage of SAML for a particular application. By agreeing to support a particular SAML profile (as opposed to the complete specification set), parties who wish to exchange SAML messages have a much simpler job of achieving interoperability. Generally, a SAML profile stipulates how particular statements are communicated using appropriate protocol messages over specified bindings.
For instance, the Web Browser SSO Profile specifies how SAML authentication assertions are communicated using the Authentication Query and Response messages over a number of different bindings in order to enable Single Sign-On for a browser user.
Conformance programs test for compliance with a standard and define a baseline of functionality that improves the chances a product will interoperate with that from another vendor. Acknowledging that the functional requirements of an implementation depend on the role that a deployment of that implementation will be expected to play within federated transactions, SAML 2.0 defines a number of different 'modes' in which an implementation may operate. For instance, if it were the case that a particular SAML implementation had been built specifically to support SSO scenarios in which it consumed but did not create SAML authentication statements, a vendor could choose to test their product's conformance to the 'Service Provider' conformance mode rather than the 'Identity Provider' mode.
For each operational mode, SAML 2.0 specifies what are the features (combinations of protocols messages and bindings) that must be supported by an implementation if it is to lay claim to supporting that mode. The 'lite' modes generally restrict an implementation from supporting particular functionality. For instance, the 'Service Provider Lite' mode forbids an implementation from supporting the Name Identifier Management protocol. There are also two extended modes that layer additional required features on top of the basic conformance modes.
As web services promise to enable integration between business partners through loose-coupling at the application and messaging layer, federation does so at the identity management layer by insulating each domain from the details of the others identity management infrastructure (e.g. how they authenticate their users).Upon its ratification (expected in early 2005), SAML 2.0 is expected to become the primary standard for federated identity.
SAML provides the federated identity building blocks on which other federated architectures can be constructed. With SAML 2.0 now providing a stable and full-featured federated identity security infrastructure, focus can now shift to this work. For instance, the Liberty Alliance's ID-Web Services Framework (Liberty ID-WSF) defines a framework for identity-based web services that leverages the SAML layer. Liberty ID-WSF uses SAML as the mechanism by which the authentication status of a user and the identity and authorizations of web sites can be communicated as part of a SOAP request for some piece of that user's personal information (e.g. their online calendar).