Chapter 11: The Liberty Alliance Project

This chapter offers a technical introduction to the Liberty Alliance Project (also referred to as “Liberty” for short). The Liberty Alliance Project is an effort, initiated by Sun Microsystems and now involving more than 120 companies, with the goal of facilitating authentication on the Web for both human users and automated mechanisms (both types referred to as “Principals” in the Liberty technical documentation). Though enhanced authentication technologies for automated mechanisms will become as equally critical as for human users (particularly for Web Services), the examples of this chapter will focus on human Principals since we, as humans, are personally familiar with the challenges of handling multiple local identities. The technical details presented are based on Liberty Alliance Project specifications that were released in July of 2002 (available from the Liberty Web site at http://www.projectliberty.org).

Readers are encouraged to first visit the Liberty Web site to view the multimedia general introduction to Liberty before delving into the technical details presented in this chapter.

What Does the Liberty Alliance Project Have To Do with Web Services?

What does the Liberty Alliance Project have to do with Web Services? The goal of Web Services is to make it easy for varied organizations to link their systems. The goal of Liberty is to allow different Web sites to cooperate on behalf of their clients to facilitate more seamless and intuitive experiences. In some cases, this cooperation will entail Web Services communication among multiple Web sites on behalf of those Principals.

When Web Services are being performed on behalf of a human Principal, what happens when that individual has identities registered with some of those organizations? For example, suppose a Principal’s preferences at one organization ought to determine the response of a Web Service request from another organization with which the Principal is also affiliated. Will those organizations’ Principals have to log in at each organization that participates in the overall Web Service? For an efficient, cost-effective, and profitable Web Service, the elimination of unnecessary human interaction is paramount.

So, for Web Services to reach their full potential, a means of federating existing Web identities and enabling single sign-on is necessary—and that is the purpose of the Liberty Alliance Project.

But in addition to the value of cross-domain authentication of humans, there is a need for cross-domain authentication of automated mechanisms, namely applications calling Web Services. These applications, too, will often need to be authenticated, as they interact with other Web Service–enabled applications over the Web. For example, digital media content providers may only allow their content to be accessed through Web Services by media players known to have certain digital rights management (DRM) capabilities. A media player requesting content from one or more content providers would first need to be authenticated, perhaps by proxy, through an identity provider that specializes in registering DRM-certified media players.

Terms to Remember

Before we go any further, some common Liberty terms and namespaces need to be highlighted.

Identity Provider

A provider of Principals’ identities that asserts the authenticity of a Principal to other identity providers and service providers (defined next).

Service Provider

This is a provider of services that the Principal may wish to use, but that does not assert the authenticity of a Principal to other providers.

Provider

This can be either an identity provider or a service provider.

Circle of Trust

A circle of trust is a community of service providers and identity providers with business relationships that have joined together to enable new secure experiences for the Principals whose identities they hold.

Principal

Principals are the entities who have, or will have, one or more identities on the Web. Principals will often be human users, but as Web Services make it easier for various software and devices to interact over the Web, it must be remembered that they, too, may be seen as Principals. The Liberty Alliance Project documentation intentionally uses the word “Principal” rather than “user” to emphasize this reality.

Local Identity

This is the identity a Principal has with a specific provider.

Federated Network Identity

This is a set of local identities that recognize each other’s existence and can work with each other through Liberty protocols.

Namespace Prefixes Used

The following namespace prefixes are used in this chapter:

• ds XML Signature (http://www.w3.org/2000/09/xmldsig#)

• saml SAML assertion namespace (urn:oasis:names:tc:SAML:1.0:assertion)

• samlp SAML protocol namespace (urn:oasis:names:tc:SAML:1.0:protocol)

Example Players

The examples in this chapter will be based on a scenario involving the following characters:

• Joan A Web user who wishes she didn’t have to keep track of so many local identities.

• IDP1 An identity provider through which Joan has her primary identity information. Joan will leverage her identity at IDP1 in order to simplify the burden of tracking local identities.

• BigWebRetailer An online retailer at which Joan has a local identity and which is part of IDP1’s circle of trust.

• Delivery A worldwide parcel delivery company at which Joan has a local identity and which is part of IDP1’s circle of trust.

The following sections illustrate the Liberty-defined communications that will occur among the three Web sites above in order to enable more seamless browsing and purchasing experiences for Joan.

Creating Circles of Trust Among Identity Providers and Service Providers

In order to protect users’ privacy and organizations’ reputations, exchanging identity information only makes sense among organizations that have established trust relationships and the legal agreements to back up those trust relationships. (Liberty does not attempt to standardize what these legal agreements among providers would contain.)

Once a legal framework has been established between an identity provider and a service provider, the first technical step required is the exchange of metadata. Provider metadata primarily consists of the URLs of those endpoints that a provider hosts and that other providers must be aware of; its communication is accomplished through the exchange of provider descriptors. Specifically, the identity provider publishes an identity provider descriptor, and the service provider publishes a service provider descriptor.

Both types of descriptors contain the following information.

ProviderID

This is a provider’s identifier (a URI).

ProviderSuccinctID

This is a succinct provider identifier.

KeyInfo (from the XML Signature Namespace)

This is the provider’s public key (see Chapter 8 for information on public key management).

SoapEndpoint

This is the provider’s SOAP endpoint.

SingleLogoutServiceURL

This is the URL to which logout notification messages are to be sent.

SingleLogoutServiceReturnURL

Once single logout has been achieved, this is the URL to which further incoming logout notification messages will be redirected.

FederationTerminationServiceURL

This is the URL to which federation termination notices are to be sent.

FederationTerminationServiceReturnURL

Once a federation has been terminated, this is the URL to which further federation termination notices will be sent.

An identity provider descriptor also includes a SingleSignOnServiceURL element to identify where authentication requests are to be received.

A service provider descriptor includes the following additional information.

AssertionConsumerServiceURL

This is the URL for receiving assertions from identity providers.

FederationTerminationNotificationProtocolProfile

This is the profile of the Federation Termination Notification Protocol that the identity provider should use.

SingleLogoutProtocolProfile

This is the profile of the Single Logout Protocol that the identity provider should use.

AuthnRequestsSigned

If “true”, this indicates that the service provider always signs its authentication requests.

Example: IDP1 and BigWebRetailer Create a Circle of Trust

IDP1 and BigWebRetailer want to enable their users’ identities to be federated; IDP1 is always on the lookout for means of better serving its users, and BigWebRetailer wants to make it easy for IDP1’s users to find, purchase, and deliver products.

Here is the IDP1’s identity provider descriptor:

<IDPDescriptor>   <ProviderID>http://www.idp1.xom</ProviderID>   <ProviderSuccinctID>K2H6H9</ProviderSuccinctID>   <ds:KeyInfo>...</ds:KeyInfo>   <SoapEndpoint>http://www.idp1.xom/soap</SoapEndpoint>   <SingleLogoutServiceURL>       http://www.idp1.xom/liberty/slo   </SingleLogoutServiceURL>   <SingleLogoutServiceReturnURL>       http://www.idp1.xom/liberty/slo_return   </SingleLogoutServiceReturnURL>   <FederationTerminationServiceURL>       http://www.idp1.xom/liberty/term   </FederationTerminationServiceURL>   <FederationTerminationServiceReturnURL>       http://www.idp1.xom/liberty/term_return   </FederationTerminationServiceReturnURL>   <SingleSignOnServiceURL>       http://www.idp1.xom/liberty/sso   </SingleSignOnServiceURL> </IDPDescriptor>

Here is BigWebRetailer’s service provider descriptor:

<SPDescriptor>   <ProviderID>http://www.bigwebretailer.xom</ProviderID>   <ProviderSuccinctID>084NYY</ProviderSuccinctID>   <ds:KeyInfo>...</ds:KeyInfo>   <SoapEndpoint>       http://www.bigwebretailer.xom/soap   </SoapEndpoint>   <SingleLogoutServiceURL>       http://www.bigwebretailer.xom/liberty/slo   </SingleLogoutServiceURL>   <SingleLogoutServiceReturnURL>       http://www.bigwebretailer.xom/liberty/slo_return   </SingleLogoutServiceReturnURL>   <FederationTerminationServiceURL>       http://www.bigwebretailer.xom/liberty/term   </FederationTerminationServiceURL>   <FederationTerminationServiceReturnURL>       http://www.bigwebretailer.xom/liberty/term_return   </FederationTerminationServiceReturnURL>   <AssertionConsumerServiceURL>       http://www.bigwebretailer.xom/liberty/assertion_consumer   </AssertionConsumerServiceURL>   <FederationTerminationNotificationProtocolProfile>       http://projectliberty.org/profiles/fedterm_soap   </FederationTerminationNotificationProtocolProfile>      <SingleLogoutProtocolProfile>       http://projectliberty.org/profiles/slo_soap   </SingleLogoutProtocolProfile>   <AuthnRequestsSigned>1</AuthnRequestsSigned> </SPDescriptor>

Once IDP1 and BigWebRetailer have exchanged their descriptors, they will know to which URLs the different messages that comprise the Liberty protocols should be sent.

Single Sign-On

Single sign-on means enabling a user to sign on once, and then, without having to sign on again, access different domains that would normally be outside the scope of the primary sign-on domain. Right now, on the Web, a typical user needs to have separate local identities for almost every service she or he wants to use and then must sign on to each one individually. While it is possible for large Internet content providers to let their registered users access a variety of services (for example, e-mail, newsgroups, stock tracking) with one local identity, such integration does not normally extend outside the domain of the content provider. Hence most Internet users maintain separate identities for each banking, billing, travel, interest group, e-mail, and so forth service that they want to use. Undoubtedly, the annoyance of having to keep track of so many different identities with their varying identification (for example, username, system-defined name, e-mail address) and authentication requirements (for example, password rules) dampens the enthusiasm to use the Web and limits what the Web can do for the user.

Recognizing that the lack of a practical single sign-on architecture is no longer just a nuisance but a major obstacle to advancing the Web, Liberty takes advantage of SAML authentication assertions to accomplish single sign-on among members of a circle of trust. Figure 11-1 illustrates how Joan can be presented with her personalized BigWebRetailer page, yet be authenticated behind the scenes by IDP1.

Figure 11-1: Joan (the Principal) is authenticated by IDP1 (her identity provider) when she browses to her personalized BigWebRetailer (her service provider) Web page

1. Joan goes to the BigWebRetailer Web site.

2. BigWebRetailer redirects Joan to the IDP1 Web site so that it can authenticate her.

3. Once authenticated, Joan is returned to the BigWebRetailer Web site.

4. The SAML artifact created when Joan was redirected is accessed by BigWebRetailer, then sent by BigWebRetailer to IDP1. IDP1 returns a SAML authentication assertion to BigWebRetailer.

5. If the SAML authentication assertion’s digital signature is valid, BigWebRetailer presents Joan’s personalized page to her.

Though at first sight being able to sign on once for every potential service may seem ideal, this need not be the most appropriate view of single sign-on. Most of us would certainly like to limit the number of identities we need to maintain, but not necessarily limit them to just one. Indeed, it may make sense to have a separate home identity, work identity, family identity, and so on. The ultimate goal is not one single identity, but to make it possible for a Principal to have just the number of identities she or he wants to have, no more and no less, and to let the Principal control what information is passed among federated identities. (Because “single sign-on” may in fact not be the most appropriate description of what Liberty enables, sometimes the phrase “simplified sign-on” is used instead.)

Identity Federation

Before IDP1 and BigWebRetailer can offer the convenience of single sign-on to Joan, they must first establish a shared identifier for Joan, After all, if IDP1 is to issue an assertion as to the authentication status of Joan and have BigWebRetailer be able to use it, IDP1 and BigWebRetailer have to be able to agree that it is indeed Joan for whom the assertion was created. Both IDP1 and BigWebRetailer must share some common identifier for Joan so that they can use it in their communications on her behalf. The process by which IDP1 and BigWebRetailer establish this shared identifier is called identity federation.

Both identity federation and the subsequently enabled single sign-on are realized through Liberty’s authentication protocol in which a provider sends an AuthnRequest (authentication request) message to an identity provider and receives an AuthnResponse (authentication response) message in return. An AuthnRequest message extends SAML’s request type and specifies the following.

Provider ID

This is the requestor.

IsPassive

This indicates whether the identity provider may actively query the Principal or not.

ForceAuthn

If set to “true”, the identity provider must authenticate, or reauthenticate, the Principal before responding. Note: IsPassive must be set to “false” if ForceAuthn is set to “true.”

Federate

This indicates whether the corresponding identities are to be federated or not.

Protocol Profile

This is the protocol profile that the service provider wishes to use for the response. If the element is not specified, the default protocol profile is

http://projectliberty.org/profiles/brws-art

AuthnContext

This is information regarding the preferences of the service provider with respect to how the Principal should be authenticated.

RelayState

This is state information that will be relayed back in the response.

The returned AuthnResponse message contains a SAML authentication assertion with these Liberty-defined extensions:

IDPProvidedNameIdentifier

This is the name identifier that the identity provider will use for the Principal and that the requesting provider will also use unless it wishes to specify another one through a RegisterNameIdentifierRequest message (described later in “Name Registration”).

AuthnContext

This is the authentication context that was used by the identity provider when it authenticated the Principal. The requestor may check this information to see if it is equivalent to the requested authentication context and/or is acceptable. Authentication context refers to the processes, technologies, and mechanisms used by the identity provider in order to authenticate Principals.

ReauthenticateOnOrAfter

This is a time when the requestor should request a reauthentication from the identity provider.

SessionIndex

This indicates to which session between the requestor and identity provider the AuthnResponse pertains. This value, if specified, is used when coordinating the single logout of the Principal.

Example: Joan Chooses to Federate Her BigWebRetailer Local Identity with Her IDP1 Local Identity

In this example, we follow the process that IDP1 and BigWebRetailer follow and the messages they exchange in order to enable single sign-on for Joan. Because it is the concept of identity federation that Liberty defined (as opposed to the subsequent SSO that SAML enables), we concentrate on the identity federation process here.

Before looking at what happens when Joan federates her identities, it will be helpful to consider what the situation looks like beforehand. At this point, both IDP1 and BigWebRetailer have directories listing Principals, their authentication, and other local identity information. IDP1’s directory entry for Joan might look like this:

<IDP1_Users xmlns="http://www.idp1.xom/namespaces/users"> ... <User U>   <AuthenticationInfo>...</AuthenticationInfo>   <Info>     <EMail>       <Address>[e-mail]</Address>    <Boxes>...</Boxes>   </EMail>   <Contacts>     <Contact>       <Name>...</Name>       <Address>...</Address>     </Contact>     ...   </Contacts>   ...   </Info> </User> ... </IDP1_Users> 

BigWebRetailer’s directory entry for Joan might look like this:

<BigWebRetailer_Customers      xmlns="http://www.bigwebretailer.xom/namespaces/customers"> ... <Customer C>  <AuthenticationInfo>…</AuthenticationInfo>  <Address>29 Quandary Road</Address>  <Preferences>   <Preference>Kayaking</Preference>  </Preferences> </Customer> ... </BigWebRetailer_Customers>

Note that in the above directory examples, none of the XML is predefined by Liberty: Liberty does not define how providers are to store their cross-authentication information, only how they transfer that information. The preceding XML examples are only intended to illustrate how exchanged Liberty information might be handled by two independent organizations.

One fine day, Joan decides to buy a gift for her nephew through BigWebRetailer. This time when Joan logs into BigWebRetailer, she is offered the opportunity to federate her BigWebRetailer identity with her IDP1 identity, and she accepts. Consequently, BigWebRetailer sends an AuthnRequest message to IDP1 indicating:

• Joan’s BigWebRetailer and IDP1 local identities are to be federated

• IDP1 must authenticate Joan upon receiving the request

The AuthnRequest message sent by BigWebRetailer to IDP1 would appear as follows:

<AuthnRequest      Request      MajorVersion="1" MinorVersion="0"     IssueInstant="2002-10-20T19:31:17-05:00">   <ds:Signature> ... </ds:Signature>   <ProviderID>http://www.bigwebretailer.xom</ProviderID>   <ForceAuthn>1</ForceAuthn>   <IsPassive>0</IsPassive>   <Federate>1</Federate>   <ProtocolProfile>     http://projectliberty.org/profiles/brws-post   </ProtocolProfile>   <AuthnContext>     <AuthnContextClassRef>       http://projectliberty.org/schemas/authctx/2002/05/Password     </AuthnContextClassRef>   </AuthnContext>   <RelayState>EWRJKLCVZXIUODFSAKJL</RelayState> </AuthnRequest>

Upon receiving the previous request, IDP1 authenticates Joan and returns an AuthnResponse to BigWebRetailer:

<AuthnResponse     Response     InResponseTo="9kdk-48vj-k93e"     MajorVersion="1" MinorVersion="0"     IssueInstant="2002-10-20T19:31:27-05:00">   <samlp:Status>     <samlp:StatusCode Value="saml:Success"/>   </samlp:Status>   <saml:Assertion MajorVersion="1" MinorVersion="0"    Assertion    Issuer="http://www.idp1.com    IssueInstant="2002-10-20T19:31:22-05:00"    InResponseTo="9kdk-48vj-k93e"    xsi:type="AssertionType">   <saml:Conditions NotBefore="2002-10-20T19:31:22-05:00"     NotOnOrAfter="2002-10-20T21:31:22-05:00">    <saml:AudienceRestrictionCondition>     <saml:Audience>http://www.bigwebretailer.com</saml:Audience>    </saml:AudienceRestrictionCondition>   </saml:Conditions>   <saml:AuthenticationStatement     AuthenticationInstant="2002-10-20T19:31:22-05:00"     SessionIndex="3"     ReauthenticateOnOrAfter="2002-10-20T21:31:22-05:00"     xsi:type="AuthenticationStatementType">    <saml:Subject xsi:type="SubjectType">     <saml:NameIdentifier>       qwert     </saml:NameIdentifier>     <IDPProvidedNameIdentifier>       qwert     </IDPProvidedNameIdentifier>    </saml:Subject>   </saml:AuthenticationStatement>   <ds:Signature>...</ds:Signature>  </saml:Assertion>  <RelayState>EWRJKLCVZXIUODFSAKJL</RelayState> </AuthnResponse>

The AuthnResponse includes an IDPProvidedNameIdentifier that BigWebRetailer, unless it chooses to replace it, will use as an alias for Joan. At this point, the information in IDP1’s directory entry for Joan now looks like this:

<IDP1_Users xmlns="http://www.idp1.xom/namespaces/users"> ... <User U>  <AuthenticationInfo>...</AuthenticationInfo>  <Liberty xmlns="www.idp1.xom/namespaces/liberty/circleoftrust">   <FederatedIdentities>    <FederatedIdentity       Domain="www.bigwebretailer.xom"      NameIdentifierIn="qwert"      NameIdentifierOut="qwert"/>   </FederatedIdentities>  </Liberty>  <Info>   <EMail>    <Address>[e-mail]</Address>    <Boxes>...</Boxes>   </EMail>   <Contacts>     <Contact>       <Name>...</Name>       <Address>...</Address>     </Contact>     ...   </Contacts>   ...  </Info> </User> ... </IDP1_Users> 

while in BigWebRetailer’s directory, the entry for Joan looks like this:

<BigWebRetailer_Customers> ... <Customer C xmlns="http://www.bigwebretailer.xom/namespaces/customers">  <AuthenticationInfo>...</AuthenticationInfo>  <Liberty xmlns="www.idp1.xom/namespaces/liberty/circleoftrust">   <FederatedIdentities>    <FederatedIdentity       Domain="www.idp1.xom"      NameIdentifierIn="qwert"      NameIdentifierOut="qwert"/>   </FederatedIdentities>   </Liberty>  <Address>...</Address>  <Preferences>   <Preference>Kayaking</Preference>  </Preferences> </Customer> ... </BigWebRetailer_Customers>

Note

In each of the previous two examples, a new element named “Liberty” has been introduced to carry the identity federation information. This is introduced only for clarity—Liberty did not define or stipulate how identity and service providers should store this information. For simplicity of this chapter’s examples, we will assume members of the IDP1 circle of trust have agreed to use a common format for storing Liberty information, though in reality this need not be the case.

Taking a closer look, we see the IDP1 directory entry for Joan now has

   <FederatedIdentity       Domain="www.bigwebretailer.xom"      NameIdentifierIn="qwert"      NameIdentifierOut="qwert"/>

which means that when IDP1 is communicating with BigWebRetailer and wants to reference Joan, it will use the opaque name identifier of “qwert.” Also, when IDP1 receives a message from BigWebRetailer regarding Joan, BigWebRetailer will use the opaque name identifier of “qwert” until it selects another name identifier (as the next section will explain). Similarly, the FederatedIdentity entry in BigWebRetailer’s directory entry for Joan indicates the same information.

Name Registration

As illustrated by the previous example, at the conclusion of the Liberty authentication protocol, the identity provider and service provider are both using the same name identifier for the Principal. This may be fine for the identity provider who got to specify the name identifier, but may not be acceptable to the service provider who needs to at least ensure the name identifiers it manages are unique, and who, furthermore, may want to use a name identifier that fits in with the way it allocates name identifiers.

Consequently, Liberty provides a means by which a service provider can specify the name identifier it will use for the Principal. This is accomplished by having the service provider send a RegisterNameIdentifierRequest message to the identity provider that specifies the following.

ProviderID

This is the identity of the provider issuing the request.

IDPProvidedNameIdentifier

This is the name identifier set by the identity provider (and which the identity provider will continue to use to refer to the Principal).

SPProvidedNameIdentifier

This is the name identifier that the service provider will use to refer to the Principal.

When the identity provider receives the RegisterNameIdentifierRequest, it updates its alias information accordingly and returns a RegisterNameIdentifier Response to the requesting provider indicating that the provider-provided name identifier is now effective.

Example: BigWebRetailer Requests the Use of a Different Name Identifier for Joan

To request a different name identifier for IDP1 to use for Joan when communicating with BigWebRetailer, BigWebRetailer sends this RegisterNameIdentifierRequest to IDP1:

<RegisterNameIdentifierRequest   Request   MajorVersion="1" MinorVersion="0"   IssueInstant="2002-10-20T09:32:02-05:00">  <ds:Signature>...</ds:Signature>  <ProviderID>http://www.big.webretailer.xom</ProviderID>  <IDPProvidedNameIdentifier>    qwert  </IDPProvidedNameIdentifier>  <SPProvidedNameIdentifier>    yuiop  </SPProvidedNameIdentifier> </RegisterNameIdentifierRequest> 

Example: IDP1 Responds to BigWebRetailer’s Name Identification Request

Upon receiving BigWebRetailer’s request to use a particular name identifier, IDP1 uses the name identified by the IDPProvidedNameIdentifier element to determine which Principal is the subject of the request, which happens to be Joan, and updates the name identifier it will use when referring to Joan in messages to BigWebRetailer. IDP1 then indicates its acceptance of the proposed name identifier with a RegisterNameIdentifierResponse message:

<RegisterNameIdentifierResponse   Response   InResponseTo="DKDI-EIEW-UWIQ"   MajorVersion="1" MinorVersion="0"   IssueInstant="2002-10-20T19:32:12-05:00"   Recipient="http://www.bigwebretailer.xom">  <ds:Signature>...</ds:Signature>  <samlp:Status>   <samlp:StatusCode Value="saml:Success"/>  </samlp:Status> </RegisterNameIdentifierResponse>

With new name identifier in place, the information in Joan’s IDP1 directory entry looks like this:

<IDP1_Users xmlns="http://www.idp1.xom/namespaces/users"> ... <User U>  <AuthenticationInfo>...</AuthenticationInfo>  <Liberty xmlns="www.idp1.xom/namespaces/liberty/circleoftrust">   <FederatedIdentities>    <FederatedIdentity       Domain="www.bigwebretailer.xom"      NameIdentifierIn="yuiop"      NameIdentifierOut="qwert"/>   </FederatedIdentities>  </Liberty>  <Info>   <EMail>    <Address>[e-mail]</Address>    <Boxes>...</Boxes>   </EMail>   <Contacts>     <Contact>       <Name>...</Name>       <Address>...</Address>     </Contact>     ...   </Contacts>   ...  </Info> </User> ... </IDP1_Users>

The information in Joan’s BigWebRetailer directory entry looks like this:

<BigWebRetailer_Customers xmlns="http://www.bigwebretailer.xom/namespaces/customers"> ... <Customer C>  <AuthenticationInfo>...</AuthenticationInfo>  <Liberty xmlns="www.idp1.xom/namespaces/liberty/circleoftrust">   <FederatedIdentities>    <FederatedIdentity      Domain="www.idp1.xom"      NameIdentifierIn="qwert"      NameIdentifierOut="yuiop"/>   </FederatedIdentities>  </Liberty>  <Address>...</Address>  <Preferences>   <Preference>Kayaking</Preference>  </Preferences> </Customer> ... </BigWebRetailer_Customers>

Now, suppose Joan also chooses to federate her Delivery identity within IDP1’s circle of trust and in the process of doing so, IDP1 selects the name identifier of “asdfg” to refer to Joan when communicating with Delivery, and Delivery selects the name identifier of “hjkln” to refer to Joan when communicating with IDP1. Here’s what IDP1’s and Delivery’s directory entries for Joan would look like (for simplicity, we assume Delivery’s directory architecture happens to be identical to IDP1’s and BigWebRetailer’s):

<IDP1_Users xmlns="http://www.idp1.xom/namespaces/users"> ... <User U>  <AuthenticationInfo>...</AuthenticationInfo>  <Liberty xmlns="www.idp1.xom/namespaces/liberty/circleoftrust">   <FederatedIdentities>    <FederatedIdentity      Domain="www.bigwebretailer.xom"      NameIdentifierIn="yuiop"      NameIdentifierOut="qwert"/>    <FederatedIdentity      Domain="www.delivery.xom"      NameIdentifierIn="hjkln"      NameIdentifierOut="asdfg"/>   </FederatedIdentities>  </Liberty>  <Info>   <EMail>    <Address>[e-mail]</Address>    <Boxes>...</Boxes>   </EMail>   <Calendar>...</Calendar>   <Groups></Groups>   <Contacts>     <Contact>       <Name>...</Name>       <Address>...</Address>     </Contact>     ...   </Contacts>   ...  </Info> </User> ... </IDP1_Users>

The information in Joan’s Delivery directory entry looks like this:

<Delivery_Customers xmlns="http://www.delivery.xom/namespaces/customers"> ... <Customer C>  <AuthenticationInfo>...</AuthenticationInfo>  <Liberty xmlns="www.idp1.xom/namespaces/liberty/circleoftrust">   <FederatedIdentities>    <FederatedIdentity      Domain="www.idp1.xom"      NameIdentifierIn="asdfg"      NameIdentifierOut="hjkln"/>   </FederatedIdentities>  </Liberty>  <Address>...</Address>  <Preferences>   <Preference>Next day</Preference>  </Preferences> </Customer> ... </Delivery_Customers>

A key privacy-enabling feature of the Liberty specifications is the requirement placed on the identity provider to ensure that the name identifiers it uses for a Principal must be unique across the multiple service providers that a particular Principal may federate to. Returning to the example, while IDP1 uses the string “qwert” to identify Joan in transactions with BigWebRetailer, it uses the string “asdfg” to identify Joan to Delivery. Consequently, BigWebRetailer and Delivery are not given any hook on which they could inappropriately (without Joan’s consent) share information about Joan.

Liberty Leading Web Services

This chapter has so far concentrated on how Liberty enables single sign-on for Principals. We have seen that the only information that an identity provider and service provider need exchange about a Principal is a meaningless identifier that can act as an alias to that Principal. But, if we consider the directory entries that IDP1, BigWebRetailer, and Delivery all maintain for Joan, we can imagine another class of information that could be shared.

Looking at the stylized directory entries, we notice there are some attributes that are likely to be duplicated across all the different providers; Joan’s e-mail and shipping address are two such examples. The implication of this duplication is, of course, that the burden of maintaining this information and keeping it up-to-date and synchronized falls squarely on Joan. If the information changes (when she moves, changes her e-mail, and so forth), it will not be easy for Joan to update all the different copies.

If such information were to be stored at a single Web site, it would be much simpler for Joan to keep it up-to-date. When other Web sites required this information, they would issue a request to the storing site for the particular piece. The storing site would release the information to the requestor only if the request was in conformance with the Principal’s privacy preferences for their personal information. The advantage to the requesting site is clear as well—they are no longer responsible for storing this information or providing interfaces for its maintenance, and have a greater chance of it being up- to-date.

Liberty will use Web Services to enable this sharing of Principal attribute information. The following examples discuss how the different providers at which Joan has federated her identities can use Web Service messages in order to go beyond single sign-on for Principals.

Example: Joan Buys a Gift Through BigWebRetailer and Ships It Using Delivery

Now that Joan has federated her IDP1, BigWebRetailer, and Delivery local identities, it becomes much easier for her (and the Web Services acting on her behalf) to use the Web to accomplish multidomain tasks.

Joan wants to buy a gift for her nephew through BigWebRetailer and ship it using Delivery. Thanks to Liberty, Joan’s federated network identities, and her prior selection of personal and privacy preferences, IDP1, BigWebRetailer, and Delivery can work seamlessly together sharing the minimal amount of information about Joan needed to get the job done. Let’s look at the highlights of the process using psuedocode to illustrate RPC Web Service calls.

Once Joan has bought the gift for her nephew, BigWebRetailer immediately displays a list of Joan’s preferred shippers. How does BigWebRetailer know who Joan’s preferred shippers are? By asking IDP1 with which shippers Joan has federated her identities in IDP1’s affinity group.

// BigWebRetailer's source code // Use IDP1's AffinityGroup.Query() web service to find out which shippers are // Joan's federated network identity.  The first parameter is BigWebRetailer's // alias it uses for Joan when communicating with IDP1.  List shippers = IDP1.AffinityGroup.Query("yuiop", "shippers"); // Display list of shippers to Joan through GUI and note which one she selected  Shipper shipper = GUI.Display("Select a shipper", shippers);

Joan has selected Delivery as her shipper. BigWebRetailer now needs to inform Delivery that Joan wants to ship her item through them. Because BigWebRetailer is not permitted to know the alias Joan uses with her selected shipper, and the selected shipper is not permitted to know which alias Joan uses for BigWebRetailer, BigWebRetailer asks IDP1 (through a Web Service) for the shipper’s alias for Joan—which it will return encrypted with the shipper’s encryption public key:

EncryptedAlias encryptedAlias     = IDP1.AffinityGroup.QueryAliasByProvider("yuiop", shipper);

In the above call, the first parameter is BigWebRetailer’s alias for Joan and the second is the shipper’s identity. IDP1 determines which user is being queried by matching the specified alias with the caller (BigWebRetailer) to determine the user is Joan. Then IDP1 finds out the alias for Joan used by the specified provider (Delivery), encrypts that alias so only Delivery can decrypt it, and returns it to BigWebRetailer.

With the encrypted alias, BigWebRetailer can now call Delivery’s Web Service for delivering an item for a user. The shipper in the following Web Service call would, of course, represent Delivery.

 shipper.Deliver(item, encryptedAlias, uriForGUI); 

Once BigWebRetailer’s application has called Delivery’s deliver() Web Service, Delivery looks to IDP1 to obtain Joan’s list of contacts so Delivery can automatically present a list of possible destination addresses to Joan. Doing so saves Joan the labor of reentering her nephew’s address (and possibly making an error doing so). Delivery’s source code looks like this:

// Delivery's source code WebService method Deliver( Item item, EncryptedData encryptedAlias,                                                           URI uriForGUI) {   // Get decrypted form of alias   Alias alias = decrypt(encryptedAlias);   // Get contacts from IDP1's GetContacts() web service for the alias   Contacts contacts = IDP1.Principal.GetContacts(alias);   // Ask Principal to select an address; the list of addresses is generated from   // the Principal's list of contacts.   Address addressRecipient = GUI.Display("Select the recipient's address",                                                       contacts, uriForGUI);    // Ship item to recipient's address  ship(item, addressRecipient); }

Now, what would have happened without Liberty? BigWebRetailer would have had no way of knowing which shipping companies Jane deals with other than by having Jane specify one. Once transferred to Delivery’s Web site, Jane would have to log in again, and Delivery would have required Jane to enter all the details about the recipient’s address.

Just because a Principal has chosen to federate her or his local identities does not mean any local identity should necessarily have access to all information within another local identity. In fact, Liberty allows federations to be unidirectional, so, for example, IDP1 may have no access to information under Joan’s BigWebRetailer identity. But, thanks largely to XML, access can be more than an all or nothing proposition; for example, Joan may prefer that BigWebRetailer not have access to her IDP1 list of contacts and that certain contacts remain inaccessible to her non-IDP1 local identities. Providers may wish to consider an XACML-enabled approach to define which local identity information is accessible to other providers.

Defederating a Local Identity

Principals must be able to defederate their identities. In other words, a Principal who has previously federated an identity must be able to remove that identity from the federation of identities she or he has established.

There are myriad reasons why defederation might happen. For human users, it may simply be that a user decides she or he prefers maintaining separate identities or perhaps wants to federate an existing service provider identity with another identity provider. For B2E scenarios, an employee’s identity would need to be defederated when that employee left the company. For automated Principals, it may often be that federation is only required for a specific activity period, and therefore it makes sense to simply federate at the beginning of that activity period and defederate at the end of it.

To defederate an identity, a FederationTerminationNotification is sent from the service provider (to which the identity is registered) to the identity provider. The FederationTerminationNotification message specifies the following.

ProviderID

This is the identifier of the provider in which the local identity specified by the name identifier is registered.

saml:NameIdentifier

The name identifier referencing the local identity is to be defederated.

Example: Joan Defederates One of Her Local Identities

Joan decides to defederate her Delivery identity. The following message would then be sent to IDP1 on her behalf:

<FederationTerminationNotification   Request   MajorVersion="1" MinorVersion="0"   IssueInstant="2002-10-20T19:39:15-05:00">  <ds:Signature>...</ds:Signature>  <ProviderID>http://www.delivery.xom</ProviderID>  <saml:NameIdentifier>hjkln</saml:NameIdentifier> </FederationTerminationNotification>

Single Logout

Single logout, is of course, essential to the security of a single sign-on system. In Liberty, a LogoutNotification is sent to all providers other than the one in which the Principal has directly logged out. A Principal may initiate a single logout from either an identity provider or service provider. If initiating a single logout from an identity provider, that identity provider alerts all other affiliated providers that the Principal is logging out, and those providers then log out the Principal. If a Principal initiates a single logout from a service provider, that service provider alerts the identity provider which then alerts the other service providers.

The LogoutNotification message specifies the following.

ProviderID

This is the provider issuing the notification.

saml:NameIdentifier

This is the name identifier of the Principal that logged out.

SessionIndex

This is the same session index that was specified in the authentication assertion during sign-on. If no session index was specified at sign-on, no session index is required at logout.

Example: Joan Logs Out from BigWebRetailer

<LogoutNotification   Request   MajorVersion="1" MinorVersion="0"   IssueInstant="2002-10-20T19:41:18-05:00">  <ds:Signature>...</ds:Signature>  <ProviderID>http://www.bigwebretailer.xom</ProviderID>  <saml:NameIdentifier>    yuiop  </saml:NameIdentifier>  <SessionIndex>3</SessionIndex> </LogoutNotification>

Security in Liberty

Because this chapter’s primary purpose is a basic introduction to Liberty, it has focused on the fundamental mechanisms for managing network identities without going too deeply into the security protections that are an essential part of realizing Liberty.

Due to the paramount importance of authentication in Web Services security, the Liberty protocol itself and its implementations must be absolutely secure if they are to be of any use at all. Consequently, Liberty makes use of XML Signature and encryption to protect the authenticity, integrity, and confidentiality of its messages. We have also seen that Liberty makes use of SAML assertions and that XACML would be valuable for fine-tuning what information about a Principal may be accessed and how. Liberty, then, provides an excellent example of how many of the security technologies discussed in this book complement each other.

Liberty also minimizes the risk of attack by being designed to work without exchanging information that would unnecessarily expose user information. For example, opaque name identifiers (for example, “nhyujmkil”) are used to refer to users rather than a user’s local domain identifier (for example, “JoeSmith”).

Liberty Today, Liberty Tomorrow

Liberty’s current focus is on enabling more seamless interactions between Principals and the multiple Web sites with which they maintain identities. The primary identities are the Principals, and Web businesses authenticate each other in order to provide new experiences to these Principals—using Web Services to accomplish this. Consequently, Liberty can be thought of as a consumer of Web Services technology. It is also possible to imagine the opposite relation —Web Services (unrelated to a Principal’s browsing experiences) using some of the same concepts, technologies, and infrastructure established by Liberty—for instance, the concept of SAML authentication assertions being used to enable third-party mediated trust could be applied to Web Services; a SOAP client first authenticating to a SAML authentication authority (through a SOAP interface) in order to receive a SAML assertion that could be presented to the desired Web Service as an identity token.

Give Me Liberty or Give Me Passport

As well as the Sun-initiated Liberty Alliance Project, Microsoft has put forth the .NET Passport initiative as a means to achieve a cohesive authentication experience for Internet Principals. Passport’s current model (that of Passport.com being the single authentication authority) is very different than Liberty’s distributed model. But the Passport roadmap includes support for Kerberos and it is likely that Passport could support something more akin to Liberty through Kerberos’s support for cross-realm authentication. At the time of writing, it should be noted that while much good work has gone into both Liberty and Passport, historically we are only at the beginning of tackling the challenges of network identity management. New Web technologies (including many of those detailed in this book) have been most successful and profitable when competitors cooperate to produce the best solution. Fortunately, it appears at present that, while technical challenges remain, it may very well be that Liberty and Passport will work together.

Indeed, there are scenarios currently possible in which Passport and a Liberty circle of trust could meaningfully coexist. For instance, if a Liberty identity provider were to also join the Passport community (as a member Web site), it would be possible for a Principal to authenticate to Passport in order to access their account at the identity provider—which could subsequently issue a SAML authentication assertion such that the Principal could access their identities at Liberty-federated service providers. The Liberty identity provider would play the role of a bridge between the two communities and map the different protocols.

The recent submission of WS-Security (of which Microsoft was an initial author) to OASIS, and its modification to support SAML as a peer of Kerberos tickets and X.509 certificates, is an encouraging sign for more meaningful interoperability between Passport and Liberty. Microsoft has indicated that Passport and its TrustBridge product will build on WS-Security and Kerberos, and has given some indication that it will use SAML to some extent. Additionally, many of the same companies working on Liberty are also active in SAML and will contribute to WS-Security.