Making ID Management Manageable

A federated ID model lets a user authenticate with one company or Web site, and get personalized content and services from any of the federated organizations in that "circle of trust." In other words, a financial services company and an online retailer, for instance, can share a customer's ID information during a transaction, rather than each having to store and manage separate credentials for each user account.

To really understand the Liberty Alliance's federated-security model, you first have to comprehend the alliance's jargon. A network identity is the conglomeration of your personal information--the bits and bytes that represent you in a myriad of databases scattered around the world. It can include your name, user name, phone number, Social Security number, medical records, and identifying numbers from your driver's license, passports and employee ID. It also may include personal preferences such as your airline seating habits, musical tastes, cell phones and wireless e-mail devices.

One Sign-On Fits All

With a federated network ID, a user's multiple network identities from different accounts--with an airline and a car-rental agency, for instance--are linked, not stored at one site. This is the beginning of the single sign-on paradigm for the Internet. An employee could book a flight with an airline and reserve a car with a rental agency without having to sign on and reauthenticate with the rental company site separately. This federated ID model offers business partners and employees more personalized online service, as well as more security and control over which personal information is used.

It works like employee provisioning and single sign-on systems, which reconcile disparate user names for an individual across various corporate systems. If a user authenticates as jsmith to the corporate domain, for example, but logs on to the HR system as John.Smith, a federated network recognizes that both IDs are tied to the same person. It can then log John Smith on to the HR system from the corporate domain automatically, and he doesn't have to log on to the HR system separately.The Liberty Alliance's circle of trust is a group of two or more businesses or service providers--banks, online retail stores or financial services companies--that share network IDs. These organizations operate under specific business agreements that dictate how they use the identities and conduct business.

The business client or consumer determines which elements of his or her identity information are shared among service providers in a circle of trust. The Liberty Alliance recommends that you notify the user about which information you're collecting. The user should give his or her consent for the ID information being exchanged among the different online sites in a circle of trust.

This "opt-in" process requires that the user agree to share information from Site A with Site B (see "Step by Step," page 63). The user confirms the information-sharing agreement when he or she arrives at the second site (B). From that point on, he or she only has to log on to one of those sites. That simplifies things for the user, and lets a business offer its clients ease of use and personalization features.

The circle of trust may sound a lot like Microsoft's Passport, but it's very different. First, the Liberty Alliance is producing specifications based on open standards, such as SAML (Security Assertion Markup Language), XML, HTTP and WSDL (Web Services Description Language); Passport is a Microsoft proprietary service based solely on Kerberos. Passport runs on Windows and Internet Explorer only, but the Liberty Alliance's standards can work across any operating system and browser platform.

Liberty specifications aren't interoperable with Microsoft's Passport, but that doesn't mean the two won't ever meet: An ID provider acting as both a Passport site and part of a circle of trust can map between the two identity technologies (see "At Liberty To Show Your Passport," below).

The Liberty Alliance uses open standards from the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS) in its specs. The earlier Version 1 and 1.1 alliance specs recommend using a third-party domain service to store a user's cookie. Then any site within the domain's circle of trust could read that cookie.Although that option remains part of the most recent Liberty Alliance spec, Version 1.2, it's no longer encouraged because cookie management and reading cookies across domains pose security risks--and raise the ire of privacy-minded consumers.

The new version also recommends OASIS' SAML as a way to pass identity information between two sites. SAML is an XML framework for exchanging authentication and authorization data between different security systems and Web services. With SAML, identity information is hidden for privacy reasons so it can't be traced to the user. This provides better security for personal data, but requires a high level of trust between the service provider and identity provider.

The Liberty Alliance spec includes two methods of passing this information among the identity provider, user agent (browser) and service provider, both of which use browser-redirection (see "A Federation of Federations").

One method is to use HTTP get to pass a SAML assertion (a statement about an end user, such as an attribute). The catch is that the length of the URL and assertion can't exceed the browser's URL-length limitations. Another method is HTTP post, which doesn't have such a restriction. HTTP post lets you embed a SAML assertion within an HTML form to pass it between providers. The downside of this approach, however, is that it's more difficult to code and requires scripting to transfer the browser automatically between the service provider and the identity provider.

A SAML artifact, which is a pointer to a SAML assertion, is often used and passed via HTTP get to make implementation smoother for the browser. For the service provider to retrieve the full SAML assertion, the identifier must be visible, albeit opaque.Enter the Circle

Federation occurs when a second site or service provider joins the circle of trust. This is the process of associating a user's identity at one site with his or her identity at another. The result is a unified identity among all members in a single circle of trust, as long as the user opts in for it.

The members of the circle designate the identity provider, which typically stores the user's opt-in agreement. Even after authorizing the federation, the user still has to agree to each business or service provider association. That ensures privacy.

Of course, given the nature of the Web, you aren't really logged on to all sites at once. It's more like a single sign-on: After a user signs on to Member A, he or she doesn't have to sign on again to visit any other member of the circle. Beware, though, that if you are "Joe Smith" to Member A and "Jsmith" to Member B, you will be known throughout the circle by your logon from the first site. So if you sign on to A and then visit Member B, you'll be known on both sites as "Joe Smith." Conversely, if you sign on to Member B and then visit Member A, you'll be known as "Jsmith" to both sites during that session. This scenario also applies among business partners and inside your organization with the Liberty Alliance architecture.

Although single sign-on products have been available from vendors such as Netegrity and Oblix for some time, the Liberty Alliance standards are advancing the broader federated identity model more quickly and widely. Building a federated identity infrastructure among your business partners not only cuts overhead and simplifies ID management in-house--it also opens the door for new business opportunities within your circle of trust.Lori MacVittie is a Network Computing technology editor working in our Green Bay, Wis., labs. Write to her at [email protected].

Post a comment or question on this story.

Users can mix and match their Liberty Alliance and Microsoft Passport identities, but only if the federated organizations with which they're doing business--the alliance one and the Passport one--share the same identity provider. The identify provider is the site that acts as the go-between for both federations of identity. It translates between the Liberty Alliance's SAML-based technique and Microsoft's Kerberos-based authentication (see "A Federation of Federations" ).

If the identity provider speaks both Liberty Alliance and Passport, a client or customer can log on to sites within a Liberty Alliance federation with his or her Passport ID, and vice versa.

Microsoft already offers its Passport services, and some Liberty Alliance products are available today as well. Hewlett-Packard,Novell, Oblix, Trustgenix and WaveSet Technologies all provide software based on the Liberty Alliance specs (see "Sites To See.").How to "Opt In" to the Federation with The Liberty Alliance Model

1. Log on to Member A's site in a circle of trust. This can be a business partner, online business or service provider site.2. Member A asks if you'd like to federate your identity with other members of the circle. If you agree, the federation process begins.

3. Log on to Member B of the circle of trust. Member B sees that you have authorized federation, and asks if you want to associate your identity from Member A's site with your identity at B's site. You agree.

4. Your identities are now federated. From that point on, logging on to A's site automatically logs you on to B's, as well as to those of any other members of the circle to which you've given your authenticated identity.

5. Log off just once. When you log off one site, you are logged off all other members' sites automatically.Security white papers & research reports

Security booksWeekly vulnerability and patch newsletter

Current Internet threat report

Hewlett-Packard's IceWall SSO

Novell, the Liberty identity provider for Novell eDirectory

Oblix's NetPointTrustgenix's Trustgenix Federation Server

WaveSet Technologies' Lighthouse