The Liberty Alliance
by Paul Madsen | Pages: 1, 2

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

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.

---