Menu

The Liberty Alliance

April 1, 2003

Paul Madsen

The pieces of our identity are increasingly scattered across those companies and institutions with which we interact online. Banks, credit card companies, brokerage firms, the department of motor vehicles, insurance companies, government agencies, telephone companies -- the list is growing. Pieces of our identity are doled out across the many computer systems and networks used by our employers, ISPs, bulletin boards, instant messaging systems, and online businesses, all with little coordination, interaction, or control on our part.

Creating a federated identity infrastructure is the key to correcting this situation. For the consumer or employee, federated identity will mean a far more satisfactory online experience, as well as new levels of personalization, security, and control over identity information. The existence of such an infrastructure will open up new business opportunities, including providing economies of scale that lower business costs and expedite the growth of the Internet and ecommerce. Making this happen is what the Liberty Alliance Project is all about.

It should come as no surprise that an infrastructure defined for federated identity on the Internet will leverage the data format of the Internet, that is, XML. Liberty leverages the flexibility and firewall-friendly nature of XML significantly. This paper addresses the specific uses of XML within the Liberty Alliance specifications. Before doing so, we'll set the context in the next section by providing a brief introduction to the Liberty Alliance and explain its goals for defining a framework for federated identity.

What is the Liberty Alliance?

The vision of the Liberty Alliance Project is to enable a networked world in which individuals and businesses can more easily conduct transactions while protecting the privacy and security of vital identity information. To accomplish its vision, the Liberty Alliance will establish an open standard for federated network identity through open technical specifications that will:

  • Support a broad range of identity-based products and services
  • Enable commercial and non-commercial organizations to realize new revenue and cost saving opportunities that economically leverage their relationships with customers, business partners, and employees
  • Provide consumers with choice of identity provider(s), the ability to link accounts through account federation, and the convenience of simplified sign-on, when using any network of connected services and devices
  • Increase ease-of-use for consumers to help stimulate ecommerce

Network identity refers to the global set of attributes that are contained in an individual's various accounts with different service providers. These attributes include information such as name, phone numbers, social security numbers, addresses, credit records, and payment information. For individuals, network identity is the sum of their financial, medical, and personal data, all of which must be carefully protected. For businesses, network identity represents their ability to know their customers and constituents and reach them in ways that bring value to both parties.

The problem with the current state of network identity is that the burden of maintaining these islands of identity falls on the individual. It is the individual that is responsible for remembering the multiple user name/password pairs for each of these identity islands, and it is the individual that must manage the information that each web site maintains in order to ensure that it is both up to date and appropriate. To address the task of remembering all their user names & passwords, users will typically either try to use the same combination (which isn't always possible) or record these values elsewhere.

In either case the result is a reduction in the level of security that the user names and passwords were designed to provide. For many users, the display of a "registration page" -- on which a site asks the user for the information the site deems necessary and relevant to a transaction at hand -- is sufficient to cause the user to click away. Most users are tired of filling in forms; they've done so too many times in the past.

Federated identity will address these issues, removing from Web users some of the burden of maintaining their identity on the Web, allowing businesses interacting with these users to offer new holistic experiences. Understanding and creating the best technical infrastructure to enable these relationships to work in a digital world is the goal of the over 160 member companies within the Liberty Alliance.

How is Liberty Phase 1 using XML?

The Liberty Phase 1 specifications (released in July 2002, updated in January 2003 and available at the Liberty site at http://www.projectliberty.org) make extensive use of XML. The following sections illustrate the different applications of XML within the Liberty specifications.

SAML

SAML (Security Assertions Markup Language) is an OASIS (Organization for Advancement Structured Information Sciences) standard designed to provide a way to define user authentication, entitlements and attribute information in XML documents. Companies need a standard open framework that will enable them to build trust chains across company boundaries, heterogeneous platforms, and multiple vendor solutions.

SAML was designed to leverage the extensibility that XML enables. The Liberty Phase 1.1 specifications leveraged this flexibility, using SAML as a foundation on which to build Simplified Sign-On and Identity Federation.

Simplified Sign-On

Liberty chose to use SAML as the means by which a Principal's authentication status can be communicated between sites. The first site (in Liberty parlance, the "Identity Provider") creates a SAML Authentication Assertion which, as its name suggests, is an assertion the Identity Provider makes as to an authentication event performed by the Principal to the IdP. The SAML assertion is communicated to another site (the "Service Provider") which, based on the trust the Service Provider has for the issuing Identity Provider, will log the Principal into the Service Provider Web site as if the user had actually authenticated directly. The communication of SAML assertions between Identity Provider and Service Provider consequently enables Simplified Sign-On for the Principal. SSO is based on a single authentication to one site which allows a user to access the services of other sites without necessarily being forced to sign-in again.

The following is an example of a SAML Authentication Assertion that the Identity Provider would create and communicate to the Service Provider (some details are omitted for clarity):

<?xml version="1.0"?>

<saml:Assertion Issuer="http://IdentityProvider.com" 

                IssueInstant="2002-12-17T09:30:47-05:00">

	<saml:Conditions NotOnOrAfter="2002-12-17T09:35:47-05:00">

		<saml:AudienceRestrictionCondition>

			<saml:Audience>http://ServiceProvider.com</saml:Audience>

		</saml:AudienceRestrictionCondition>

	</saml:Conditions>

<saml:AuthenticationStatement 

      AuthenticationInstant="2002-12-17T09:30:47-05:00" >

	<saml:Subject xsi:type="SubjectType">

		<saml:NameIdentifier>342ad3d8</saml:NameIdentifier>

		<lib:IDPProvidedNameIdentifier>342ad3d8</lib:IDPProvidedNameIdentifier>

	</saml:Subject>

</saml:AuthenticationStatement>

</saml:Assertion>

An Identity Provider, named "IdentityProvider.com", is asserting to a Service Provider, named "ServiceProvider.com", that the Principal known to both of them as '342ad3d8' authenticated to IdentityProvider.com at approximately 9.30 in the morning on December 17/2002. When ServiceProvider.com receives this assertion, it will grant access to the appropriate account (that of the Principal it refers to externally as '342ad3d8') to the individual "presenting" the assertion.

The IDPProvidedNameIdentifier element in the separate Liberty namespace above demonstrates how Liberty extends the base SAML Authentication Assertion. By building on SAML in this manner (rather than defining a new syntax) Liberty was both able to deliver its Phase 1.1 specs in a relatively short time-frame (approximately 6 months) as well as take advantage of the broad support for SAML within the marketplace. Consequently, we are already seeing early implementations of the Liberty Phase 1 specification -- vendors able to leverage the support for SAML that is appearing in products (many of those companies active in the SAML initiative are also active members of Liberty).

The following diagram illustrates one scenario by which a Liberty Identity Provider and Service Provider can communicate a SAML Authentication Assertion in order to enable SSO for a Principal. In this model, rather than the Identity Provider sending the actual SAML Authentication assertion to the Service Provider, the Identity Provider initially sends only an artifact that acts as a pointer to the SAML assertion; this pointer is then dereferenced by direct communication between the Service provider and the Identity Provider.

Process Flow for SSO
Process Flow for SSO

Identity Federation

Before SAML can be used to enable SSO for a Principal, the Identity Provider and Service provider must be able to share between themselves some identifier for that Principal; otherwise, they would have no means by which to query or assert to the other the authentication status of that Principal. A key feature of the Liberty Phase 1.1 specs is the concept of identity federation (or account linkage), which is a process by which, after explicit Principal opt-in, the Identity Provider and Service Provider exchange between them a unique and opaque (a random string that, in and of itself, can not be linked to the Principal) identifier for that Principal. Subsequent communications between the Identity Provider and Service Provider on behalf of this Principal use this opaque identifier.

A distinguishing feature of the Liberty specifications is that a Principal will be known by a different opaque identifier for every pairwise identity federation they set up. This ensures that if a Principal federates their identity at an Identity Provider with two different Service Providers, the Liberty protocols themselves will not provide those two Service Providers a means to collude and inappropriately share information about that Principal (which would be trivial if the two Service Providers shared the same Global identifier for that Principal).

SOAP

SOAP is relevant for communications between Identity and Service Providers. While most communications between the Identity and Service Provider occur through HTTP redirects using the so-called front-channel, the limitations of this channel with respect to the size of the messages require alternative mechanisms for certain message types. This alternative mechanism is communication between the Identity provider and Service Provider using SOAP-based messaging directly between the two entities, thereby avoiding the limitations of the browser intermediary in the front-channel.

The distinction between the front-channel and this SOAP/Web Services based back-channel is illustrated in the following diagram.

Front-channel and SOAP-based back-channel
Front-channel and SOAP-based back-channel

While in Phase 1 the back-channel is effectively just a mechanism to avoid the limitations of the browser front-channel, it will take on greater significance in subsequent phases when different Liberty entities may need to communicate on behalf of a Principal - even when that Principal is not directly online at those entities (and consequently when there would be no front-channel available).

XML Signature

For the Service Provider to place any trust in a SAML Authentication Assertion it receives, it must be confident that the assertion was indeed created and sent by the purported Identity Provider (this claim is expressed through the Issuer attribute on the Assertion element). Most Service Providers will require that the identity of the creator/sender of the SAML Authentication Assertion be authenticated through some sort of cryptographic mechanism to prevent the release of a principal's personal information to an unauthorized entity. Digital signatures allow the identity of a signer to be reliably bound to a document or message; XML Signature provides an XML syntax for capturing signatures calculated over XML data (but not restricted to just XML data).

Liberty allows Identity Providers to calculate XML Signatures over the SAML Authentication Assertions in order to allow the recipient Service Provider to verify its authentic origin.

An overview of XML Signature is available.

Authentication Context

One particular area in which Liberty extended SAML is a concept Liberty refers to as Authentication Context; in other words, information added to the SAML Authentication Assertion regarding the details of the technology used for the actual authentication action (e.g. password versus biometric), what processes were followed in the issuance of the identity (e.g. face-to-face meeting versus Web self-registration), and other characteristics that may be relevant to the consumer of the SAML Authentication Assertion.

As an example, to notify another site that a particular SAML assertion was issued based on the Principal having authenticated using a password over an SSL-protected session, the Identity Provider will also make available an XML document describing these characteristics, an example of which might appear as:

<?xml version="1.0"?>

<AuthenticationContextStatement>

	<AuthenticationMethod>

		<PrincipalAuthenticationMechanism>

			<Password>

				<Length min="3"/>

			</Password>

		</PrincipalAuthenticationMechanism>

		<AuthenticatorTransportProtocol>

			<SSL/>

		</AuthenticatorTransportProtocol>

	</AuthenticationMethod>

</AuthenticationContextStatement>

With this additional information about the context of the authentication event, the Liberty Service Provider will be better able to make an informed decision on the level of confidence to place in the resulting SAML Authentication Assertion.

Metadata

For Liberty Identity and Service providers to communicate with each other regarding the authentication status of their users, they must already have exchanged the necessary information. Liberty defined a simple XML Schema for both Identity and Service Provider metadata.

An example of a metadata description for a Service Provider is shown below (namespace declarations are omitted for clarity). Most of the description involves the Service Provider notifying potential Identity Provider partners of the URLs at which the Service Provider maintains the individual services implementing the Liberty protocols. For instance, the AssertionConsumerServiceURL element (in bold) contains the URL to which Identity Providers should redirect the Principal's browser in order to send the Service Provider a SAML assertion for that Principal. 

<?xml version="1.0"?>

<SPDescriptor>

	<ProviderID>http://ServiceProvider.com</ProviderID>

	<ProviderSuccinctID>A9FD64E12C</ProviderSuccinctID>

	<digsig:KeyInfo>...</digsig:KeyInfo>

	<SoapEndpoint>http://ServiceProvider.com/soap</SoapEndpoint>

	<SingleLogoutServiceURL>

		http://serviceprovider.com/liberty/slo

	</SingleLogoutServiceURL>

	<AssertionConsumerServiceURL>

		http://ServiceProvider.com/liberty/assertion_consumer

	</AssertionConsumerServiceURL>

	<SingleLogoutProtocolProfile>

		http://projectliberty.org/profiles/slo_soap

	</SingleLogoutProtocolProfile>

	<AuthnRequestsSigned>1</AuthnRequestsSigned>

</SPDescriptor>

This example illustrates how the metadata description could include a KeyInfo element (shown here in bold and in a "digsig" namespace to represent that this element was defined in the XML Signature standard), a mechanism by which the Service Provider could make available its public key to Identity Providers such that these Identity Providers would subsequently be able to verify Service Provider signed requests.

What isn't shown in the example is that a metadata description would likely need to have its integrity protected through an XML Signature calculated over it in order to prevent malicious tampering.

Liberty Roadmap & XML

Liberty's first phase focused on enabling simplified sign-on through identity federation, the Liberty Identity Federation Framework (ID-FF). The Liberty Phase 2 specifications (expected in mid-2003) will provide features for enhancing identity federation and enabling interoperable identity-based web services. This forthcoming work is known as the Identity Web Services Framework (ID-WSF).

The Liberty Phase 1 specifications released in July 2002, and updated in January 2003, provide the plumbing for federated identity management. These specifications provide standards for simplified sign-on and federation or "linking" among disparate accounts within a group of businesses that have already established relationships.

The Liberty Phase 2 specifications, which are expected in mid-2003, will enhance Liberty's Identity Federation Framework and introduce the ID-WSF. It outlines the technical components necessary to build interoperable identity-based web services that meet specific business needs and also protect the privacy and security of users' shared information.

Phase 2 also includes the introduction of Liberty Alliance Identity Services Interface Specifications (ID-SIS), a collection of specifications built on the ID-WSF. These specifications will provide a standard way for companies to build interoperable services like registration profiles, contact books, calendar, geo-location, or alert services. The first service interface specification to be introduced is the ID-Personal Profile, which will define a basic profile template that can be used to build a registration service.

As it did for Phase 1 ID-FF, XML will play a key role in Liberty's ID-WSF and subsequent phases. For instance, to enable the permission-based attribute sharing necessary for web-based identity services that enable users to control their data, there will need to be XML schemas for capturing a users core profile (e.g. their shipping address, their cell phone number, etc.) and a protocol for requesting such profile information.

Those readers interested in learning more are encouraged to visit the Liberty Alliance site to download the Phase 1.1 specifications and to obtain the "Introduction to the Liberty Alliance Identity Architecture" whitepaper.