Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

The first taste of Liberty

Sign on once, log in everywhere

  • Print
  • Feedback

Page 2 of 4

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.

  • Print
  • Feedback

Resources