What annoys you most on the Web today?

For me, having to remember dozens of Website usernames and passwords surely surpasses all other inconveniences. Whether you wish to chat on JavaWorld's forums or keep up with the news on your favorite current affairs Website, chances are you will be asked at some point to enter your username and password. Following closely behind that aggravation are the bothersome HTML forms you must fill out to obtain your user IDs in the first place.

Username and password boxes are annoying because they present an experience without close parallel in the off-line world. When returning home after a long day's work, once you unlock your front door, you can freely move about without identifying yourself to your kitchen appliances, your bathtub, or the television set. Inside your home, you gain complete access even to your checkbook without that checkbook asking for a username and password.

Even offices work similarly. Once you are permitted to enter an office building, you can typically move about without having to be reauthenticated to grab a cup of java from the lunch room or to drop by your coworker's cubicle for a quick chat. Homes and offices, in effect, are circles of trust: once admitted inside those circles, you are mostly free to go about your business.

Currently, the Web is a seascape of myriad user account islands, and Websites fail to share users' preferences. Even if you have already specified on an airline's Website that you're a vegetarian, chances are, the hotel where you'll be staying will ask for your meal preferences again. If you have children, you currently must separately specify that fact to hotels, restaurants, travel agencies, cruise lines, amusement parks, insurance companies, and the like. Next to usernames, passwords, and personal information request forms, isolated user preferences stand high on my list of awkward Web user experiences.

The Liberty Alliance Project specifications offer a possible solution to the first two of those limitations. The next-generation Liberty specifications, version 2.0 due in a few months, hope to solve the third one as well. What represents a mere inconvenience for Websites may well be a showstopper for Web services. You can almost always count on a human to punch her username and password into a Web browser. But Web services do not enjoy the benefits of human supervision: they must often invoke other Web services on their own. Even if Web services execute on behalf of a human user, they can't stop and fetch their anthropomorphic master for user access information. Rather, either they must have a way to obtain access information automatically or Web services acting together to support a common goal must trust one another prior to service-to-service invocations.

Liberty addresses the needs of both existing Websites and Web services. In this article, I first introduce the specific problems that Liberty tries to solve and the solutions it proposes. Then I describe an open source Liberty implementation, the Interoperability Prototype for Liberty (IPL), and implement a simple Liberty-enabled system using IPL. That example will feature a traditional Website infrastructure, allowing you to sign on once and gain access to two Websites. The example is easy to extend to Web services.

Single sign-on

The Liberty specifications are the efforts of an industry consortium that includes some of the biggest companies using electronic commerce today. At the time of this writing, the Liberty Alliance Project has more than 150 members, and several dozen companies have already announced support for Liberty in their products. Liberty is not specific to Java. Currently, the only Java-based implementation besides the open source IPL is a commercial product, the Sun ONE Identity Server.

Liberty mirrors the way two or more businesses form a trust relationship. That trust may be forged via business arrangements or contracts. A Liberty trust relationship means that one business trusts another business's user authentication decisions. That trust lets a user log in at one site and access another site as well. Thus, the key Liberty aim is to enable single sign-on (SSO) to multiple Websites and Web services.

The more companies that participate in a circle of trust, the more useful single sign-on becomes. Since both traditional Websites and Web services may be circle-of-trust members, Liberty defines the term service provider to refer to any electronic service participating in a Liberty identity federation.

Liberty adds three refinements to a general single sign-on mechanism. First, a special Liberty circle-of-trust member is a service provider whose responsibility is user authentication—an identity provider. Liberty specifies the relationship and communication patterns among the identity providers, the service providers, and the user. Second, Liberty ensures that a user has complete control over his identity information—any manipulation of a user's identity data requires prior user consent. Finally, Liberty relies on an emerging XML standard, SAML (Secure Assertion Markup Language), to exchange authentication information between service providers.

Although Liberty separates the identity and service provider roles, in some cases, a service provider may adopt the additional role of the identity provider. In other situations, however, user authentication may be delegated to a dedicated identity provider whose sole focus is user authentication. That provider might employ more sophisticated user authentication techniques than an individual Website operator might otherwise implement. For instance, an identity provider might require a user to log in with a secure smart card, instead of just a plain old username and password, possibly increasing overall system security. Figure 1 illustrates the role of an identity provider in the context of Liberty-enabled e-commerce Websites and Web services.

Figure 1. The identity provider's role in e-commerce Websites and Web services

Scattered identities: A user by many names

While it may at first sound strange to trust a third party with user authentication decisions, delegating such decisions to an outside party extends the way electronic commerce currently works. When you decide to submit your credit card number to an e-commerce Website, you want to ensure that no one impersonates that site to hijack sensitive account information. Current practice delegates verifying a Website's identity to public certificate authorities. Organizations such as VeriSign, Thawte Consulting, and others perform due diligence about a business's legitimate identity before granting it a secure certificate. Once that certificate is issued, Website visitors trust a certificate authority's decision to vouch for the service provider's identity.

In addition to the ability of delegating authentication decisions to an identity provider, Liberty empowers users to make decisions about their online identities. Single sign-on requires some sort of cross referencing, or federating, of user accounts among circle-of-trust members. However, Liberty mandates that a user initiate any sort of federation for her identity information. In other words, once a user initiates account federation between trusting service providers, those providers can trust one another's authentication decisions and thereby offer the convenience of single sign-on. Not only do service providers have to trust one another, the user also must trust the providers: the user is also a member of the circle of trust. If a user no longer trusts a service provider, she can annul the identity federations associated with the provider at any time.

By giving users complete control over their online identity profiles, Liberty contrasts with the "big brother" view of an identity provider. According to that view, a huge, centralized database tracks a user's online identity. Since all the information needed to evaluate a user's credentials are stored in that database, all authentication requests are directed to that single identity provider.

Due to an early version of an identity provider, Microsoft's Passport, that perception is not based entirely on myth. In its first incarnation, Passport was—and still is—a big database operated by a single company that stores user passwords and other user-related data. Much controversy has surrounded Passport and for valid reasons: not only does it require a user to entrust all her identity information to a single operator, it also increases the risk of all Passport-aware services becoming inaccessible should the Passport database service itself become unavailable.

Liberty, by contrast, acknowledges that a user's identity information is likely scattered across many databases and service providers. You may store your bank account information at your bank's database, your credit card numbers at the card issuer, and your cheese preferences at the local pizza parlor's Website. Each of those accounts, in turn, might require that you authenticate yourself before accessing that data. In Liberty terminology, at each of those sites, you maintain a local identity.

Liberty does not require that you give up those local identities in favor of a master, knows-it-all account. Liberty does not even require that a third party ever learn any detail of your local identities—you will never have to give your bank Website username or password to the pizza ordering service. Instead, Liberty provides a way to create a composite, federated identity profile from all those accounts. When you form a Liberty identity federation, Liberty produces a unique way to identify the newly created federation and then maps that federation's identity to your local identities. Figure 2 shows how that works.

Figure 2. Local identities and an identity federation

As a user, you are unaware of the name or identifier of that Liberty federation. You simply log into an identity provider, which automatically logs you into your local identities. In the broadest conceptual terms, you can envision a Liberty identity federation as a hash table that de-references local identities based on a federation's own identifier. I will shortly explain how that works in practice. Before that, however, you must learn how service providers and identity providers communicate and share authentication decisions.

A gentle introduction to SAML

If you have ever built even a simple interactive Website or Web service, chances are you had to write a login module. The routine is simple: The user enters a username and password. You then capture that input and compare what the user entered with a directory or database record. If the records match, the user is logged in, or authenticated. As a final step, you may then set a session object that represents some user attributes, such as her first and last names.

In specifying those user attributes, you likely follow conventions specific to your application. For instance, you may create name-value pairs for user-related information that you obtained during user authentication and place those attributes in a servlet's session context. While that works well for a single Website or Web service, that approach might not work when multiple systems must coordinate user authentication decisions.

Consider all the types of information that may be exchanged about an authenticated user between trusting service providers. First, a user—or a subject in security argot—is likely to maintain different local identities with different service providers. That's why we need to federate those identities in the first place. The subject James Madison may be referred to as publius at the service provider federalist.org, but framer at constitution.us. Once authenticated to either of those providers, the subject is referred to as a principal. Since a subject can be authenticated to many service providers, a subject can have many principals associated with it.

When a user, or principal, is authenticated to a service provider, that provider's authentication system must decide what permissions to grant that user. Service providers often categorize their users according to access levels, such as administrators, rank and file, VIPs, guests, and so forth. Those categories are examples of the attribute types that a system may tag onto a principal following authentication.

The authentication system may also authorize a user to perform certain system actions, perhaps based on that user's access level. For instance, a manager-level user may be authorized to adjust an employee's salary figure. That type of authorization information is also associated with an authenticated principal.

The complete set of authentication and authorization information, as well as other attributes associated with a principal at the time of authentication, serve as proof of that principal's identity during his interaction with a system; those data items form assertions about the authenticated user. For example, an assertion might state that a user "may remove files owned by user." Another assertion may state that this user "may not connect to a port where the port number is less than 1024." And yet another assertion may state that the user's name is "Fred" or that the user likes peanut butter sandwiches. Figure 3 illustrates the relationship among subject, principal, and assertions.

Page 2 of 3
Figure 3. Subject, principal, and assertions. Note that assertions are the result of authentication.

Even a simple e-commerce system or Web service can require dozens or more assertions to control access to its resources. Operating systems might have hundreds of possible assertions to tag onto authenticated users. Until recently, each system defined its own way of expressing security assertions. When the objective is to share security assertions between trusting parties, there must be a common way to express assertions. That need led to the development of an XML language to express security assertions, the Security Assertions Markup Language, or SAML.

SAML itself is a merger of two previously competing XML-based languages aimed to specify security-related information, S2ML and AuthML. Currently, SAML is careering through the OASIS (Organization for the Advancement of Structured Information) open standards consortium and is poised to become the dominant security-specific XML language. Liberty relies on SAML to define and exchange shared authentication-related information.

Liberty, in effect, extends SAML to create and manage Web-based federated identities. Liberty's reliance on SAML is one of its biggest differentiators from other frameworks promising single sign-on. Liberty employs SAML's terminology and even its data structures to such a degree that at least a brief familiarity with SAML is needed to understand how Liberty works.

Specify and exchange security assertions

SAML defines XML data structures for security assertions, a simple protocol for exchanging and querying security assertions, and that protocol's bindings vis-à-vis message transport protocols, such as HTTP and SOAP (Simple Object Access Protocol). Most of the SAML message structures are designed with extensibility in mind: a particular SAML application can extend SAML's basic structures to suit that new application's needs. That extensibility permits SAML to be a universal language for security assertions. Liberty is an example of an SAML application: participants in a Liberty identity federation exchange assertions about a user with Liberty-specific SAML message extensions.

The SAML Assertion element contains the three key data items that form an authorization's by-products: information about the authentication itself, the authorization decisions made during authentication, and attributes associated with the subject. Table 1 shows an overview of the Assertion element.

Table 1. SAML's Assertion structure. Mandatory elements are bolded.

MajorVersionThe assertion's major specification version. Currently, "1".
MinorVersionThe assertion's minor specification version.
AssertionIDThe assertion's unique identifier, of the type IDType or IDReferenceType. How that ID is generated is left up to an implementation.
IssuerA string identifying the assertion's issuer. It likely takes the form of a URL or URN (Uniform Resource Name).
IssueInstantThe time when the assertion was issued.
ConditionsThe conditions that must be considered when evaluating the assertion. This element takes the form of the SAML Condition message that includes information such as time limits for this assertion's validity or the assertion's intended audience, identified by that target audience's URI (Uniform Resource Identifier).
AdviceThis optional element helps evaluate the assertion. It also introduces a form of recursion into Assertion, as this element may include a list of other assertions.
ds:SignatureAn optional XML digital signature for the assertion document.
One or more StatementsThis section actually conveys what the assertion represents. It contains a list of one or more Statement types (see below).

Table 2 illustrates the few Statement types SAML defines. A SAML application is free to extend those types or directly define a new Statement type.

Table 2. SAML statement types

Statement types  
SubjectStatementDescribes the assertion's subject (such as a user, an organization, or a Web service).
AuthenticationStatementStates that the subject was authenticated at a certain time, at a certain network location. It also indicates the means by which the subject was authenticated (AuthenticationMethod).
AuthorizationDecisionStatementThis element states what access a subject has gained as a result of authentication to a specific resource. Optionally, this element may also include the evidence the authenticator used to make the authorization decision. This statement identifies the resource by a URI. The action is of the SAML type Action and contains a string of XML data as well as a namespace identifier that gives meaning to that XML string. For instance, you may have an XML namespace Magellan and an action <magAction>DeleteMagUser</magAction>. The associated resources may have a URI http://magellan.com/useradmin/. The combination of that resource and action identifiers would imply to Magellan Travel's system that the authenticated user is permitted to perform the DeleteMagUser on the user administrator resource. The optional evidence is specified as another assertion.
AttributeStatementThis statement simply associates an arbitrary attribute with a user, specified as a name-value pair. An example of using this element is when you want to associate a user's preferences or some other application-specific information with the assertion: when a user logs in via an authentication system, that authentication system might also retrieve information such as the user's account status or meal preferences.

Of those Statements, the current Liberty specifications utilize the AuthenticationStatement statement element. But SAML can convey other types of assertion statements as well, as this example Assertion shows:

     NotAfter="2003-03-1T12:00:00Z" />

The above assertion carries two statements: an AuthenticationStatement and an AttributeStatement. The AttributeStatement, in turn, associates two attributes with a subject: the subject's meal preferences and favorite drink. The AuthenticationStatement notes the time and manner in which the subject was authenticated. Note that both the authorization and attribute statements are designed to state some information about a subject—they both are SubjectStatements. Finally, the entire assertion is valid only for about a day, as its Condition section indicates. The full range of SAML schema elements are available from the SAML Website.

In addition to XML data structures, SAML also defines a simple request-response protocol to exchange SAML messages. SAML defines a request as an abstract XML Schema element, RequestAbstractType. An SAML request message embeds a query message that can request information about a subject, a statement, or an attribute. The following SAML request queries authentication statements:


A response—of the SAML ResponseAbstractType—to that request would return a series of assertions related to the specified subject's authentication (e.g., those assertions would carry authentication statements).

Finally, the SAML specifications also define a series of protocol bindings, such as bindings for SOAP and HTTP.

As the above XML snippets indicate, SAML is very flexible, as most of its core protocol messages are defined in an extensible fashion. Due to that flexibility, SAML is fast gaining momentum as the language of choice for expressing security assertions. At the time of this writing, several Java-specific SAML bindings exist (see Resources for an example). An open source Java implementation, OpenSAML, is part of the next-generation Internet—Internet2—initiative. In addition, a Java-specific SAML binding is in the early stages of the Java Community Process as JSR (Java Specification Request) 155, Web Services Security Assertions. Once that JSR reaches final release, SAML will likely be the standard mechanism to express security assertions in Java.

Page 3 of 3

SAML and the Liberty protocols

Perhaps the easiest way to understand Liberty is to think of it as SAML with a twist: a SAML application for single sign-on and federated network identity management. Liberty enriches the basic SAML framework with metadata, schemas, and a set of protocols needed to create and manage federated network identities, and to perform single sign-on. In addition, Liberty also defines a Web redirection mechanism to support existing Web clients, such as current Web browsers.

Liberty protocols rely on extensions to the SAML request and response messages (RequestAbstractType and ResponseAbstractType) to exchange authentication assertions between identity and service providers. When an identity provider performs authentication, it issues its assertions in messages that extend SAML's AssertionType. Information about a subject, in turn, follows the format of the SAML Subject XML element. Figure 4 depicts Liberty's extensions to SAML's key data structures. A Liberty identity federation exists when a service provider trusts the assertions issued by an identity provider.

Figure 4. Liberty extensions to SAML's abstract types

Based on SAML's simple request-response pattern, Liberty specifies the following protocols:

  • The single sign-on and identity federation protocol lets a service provider obtain an authentication assertion from an identity provider. Optionally, this protocol also instructs the service provider to start trusting assertions from an identity provider, that is, to federate the user's identity at the service provider with that user's identity at the identity provider, if both parties maintain information about that user's identity.
  • When an identity provider authenticates the user, typically that identity provider creates a session with the service provider. The single logout protocol notifies both the service provider and the identity provider to terminate that session for a given principal, in effect, logging the principal out.
  • The federation termination protocol notifies both the service and identity providers to terminate a federation; it tells a service provider to no longer trust authentication assertions from an identity provider.
  • The name registration protocol lets a service provider register a name for a user with an identity provider. As I mentioned earlier, Liberty does not require a service provider to give any specific information about a user's local identity when joining a federation. Instead, that service provider may decide to register a pseudonym of its choosing for that user when joining an identity federation. The identity provider will mark that pseudonym and associate it with its own identifier for the user. The identity provider, in turn, may provide the service provider with its user identifier.

Each Liberty protocol may be used in various communication environments, including current-generation Web browsers and Web servers. The communication mechanisms and the protocol messages together form Liberty's protocol profiles. The 1.1 Liberty specifications define protocol profiles for HTTP POST, browser "artifacts," WML (Wireless Markup Language) POST, and Liberty-enabled Web services (clients) and proxies. The open source IPL that I use in the example below supports all but the last of those profiles. The example uses the HTTP POST profile. That not only keeps the example simple, but also shows how existing browsers can simply support single sign-on through identity federations.

Implement Liberty single sign-on

To illustrate the Liberty protocols, I will create a simple identity federation between two service providers, magellan.com and dwightair.com. To keep this example focused, magellan.com will also act as the identity provider. With a federated identity between those service providers in place, once a user signs into magellan.com, he is automatically granted access to dwightair.com as well. It works the other way, too: when a user signs onto dwightair.com, he will not have to log in again to access magellan.com.

The general flow to establish an identity federation is as follows:

  1. First, the user visits the magellan.com Website and logs into his account there. He is then presented with a Webpage, listing all the service providers magellan.com has a prior trust relationship with and offering the user to federate his identities across those providers. DwightAir is on that list, and the user indicates that he desires to federate his identities with that provider.
  2. Next, he is asked to log into dwightair.com, providing his creditials for that service provider. At that point, the identity provider (magellan.com, in this example), notes that a federation is formed between those two identity profiles.

If these steps don't sound very exciting—after all, the user just logs into two service providers—that's because they hide the complexity of forming the identity federation from the user. The benefit of that federation becomes apparent when the user next visits magellan.com:

  1. When authenticating the user, magellan.com delegates that authentication decision to the identity provider; in this example, the identity provider is another Web service operated by Magellan.
  2. Following the authentication, the identity provider issues a series of assertions and sends those back to magellan.com. In addition, the identity provider also establishes an authenticated session with the user's browser.
  3. When the user proceeds to dwightair.com to purchase airline tickets for his vacation, the DwightAir Website will note that a session exists between magellan.com and the identity provider. Since an identity federation exists between DwightAir and Magellan, DwightAir trusts authentication assertions that were issued for Magellan by the identity provider. The identity provider may at that point issue another set of assertions for dwightair.com, mapping the user's local identity at DwightAir to the federation's identifier for the user.

Figure 5 illustrates these steps.

Figure 5. Single sign-on with Liberty

As with the federation forming, Liberty hides much of the single sign-on protocol's complexity. Each Liberty profile exchanges messages differently. Figure 6 illustrates the message flow for the browser POST profile:

Figure 6. Single sign-on message in the browser POST profile

You may note from this message flow diagram that the browser POST profile uses HTTP's redirect mechanism to forward authentication requests to the identity provider. Because all current-generation Web browsers support HTTP redirect, Liberty works with widely deployed current technology.

Another interesting aspect to note is that a request for creating a new identity federation is carried in the same message that requests authentication from an identity provider. That message takes the form of an AuthnRequest (see Figure 4), and the response, as you may have guessed, is an AuthnResponse. The Federate element instructs the identity provider whether it should federate the principal's identity at the service provider with that principal's identity at the identity provider. The following is a fragment of a Liberty AuthnRequest message requesting identity federation:

<lib:AuthnRequest id="123456" 

You will also note that the request message specifies the protocol profile to be used (browser POST in this case) as well as the authentication method to be used. You convey the latter by referring to an authentication class defined in the Liberty specifications. The example refers to PasswordProtectedTransport.

Put it together: The simplest Liberty client with IPL

A Java-specific Liberty binding allows you to manipulate Liberty protocol messages via an API. The open source IPL defines one possible Java/Liberty binding as well as a set of utilities and servlets that help you manage identity federations and single sign-on.

In its current form, the IPL consists of four packages:

  1. The com.sun.liberty.saml package contains a full SAML-Java binding.
  2. The com.sun.liberty package provides Java bindings for the Liberty extensions to SAML messages as well as classes implementing the Liberty protocol messages. In addition, this package includes several utility classes.
  3. The com.sun.liberty.servlets package contains servlets that process Liberty messages via several Liberty profiles.
  4. The com.sun.liberty.ac package contains just two classes that represent authentication context information.

In addition to that class library, the IPL also includes a simple example application based on a set of JSP (JavaServer Pages) pages that interact with the IPL Liberty servlets in processing login requests and identity federation management. More sophisticated programming examples are included in the download package for the Sun Identity Server.

Figure 7 illustrates the JSP pages for this example and their interaction with the IPL servlets.

Figure 7. JSP pages invoke IPL servlets to support single sign-on
  • In this example, a user first accesses the protected.jsp page, using his username and password at the local service provider.
  • The user then goes from protected.jsp to federate.jsp and from there, requests federation with the identity provider. He will be asked for his username and password at the identity provider.
  • Finally, he logs out and then logs back in, this time using his identity provider username and password. At this point, the service provider trusts the authentication decisions made by the identity provider.

Free yourself from a developer's annoyance

Being able to sign on once and log in everywhere may appear to your Website's or Web service's users as magic. But, as this example shows, there is no magic to single sign-on. It's a matter of following the Liberty protocols' message exchanges and trusting authentication decisions issued by an identity provider. The more Websites you must interact with that support Liberty, the more common the single sign-on experience becomes. Currently, only Sun Microsystems' Sun ONE (Open Network Environment) product line supports the Liberty protocols, but Liberty is fast gaining industry support, and dozens of companies have announced plans to Liberty-enable their products and e-commerce Websites. The forthcoming Liberty 2.0 specifications will address issues beyond single sign-on and identity federations—for instance, they may let you share a user's preferences and other user-specific data as well.

While eliminating duplicate login and data entry forms are sure to please your Website's or service's users, introducing Liberty into your Website or Web service architecture can cut down on what surely must be the biggest annoyance in a development project: duplicating functionality. That's because Liberty can help you factor out authentication roles, on the one hand, and services that are consumers of authentication-produced information, on the other. That way you could maintain just one service (or servlet) acting as an identity provider, and your other services can rely on that identity provider's authentication assertions. Instead of developing some application-specific way to exchange security assertion information, Liberty allows you to depend on SAML data structures. As you add services to your infrastructure, those new services can leverage what's already available.

Frank Sommers is founder and CEO of Autospaces, a company focused on bringing Jini technology and Web services to the automotive software market. He is also editor in chief of the Newsletter of the IEEE Task Force on Cluster Computing.

Learn more about this topic