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 lmacvittie@nwc.com.
Post a comment or question on this story.
REPORTS
ANALYTICS
Follow 
