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.
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.
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.
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.