Give Me Liberty...
Articles and Tips: article
01 Jun 2003
"Give me Liberty, or give me death!" Patrick Henry's now immortalized demand in the early days of the American Revolutionary War seems somehow appropriate to current experiences on the Web. Every site has an account. Every account has a name-and many of the names are distinct. Every name has a password, and several have password rules-different rules-resulting in different passwords. Too many passwords, too many identities, too many rules-and now I'm locked out of my own account! Give me liberty! Liberty from that slow, agonizing death by Net complexity! We've all felt that way at one time or another. On the Web we can be anybody, but too many times the result is NMPD (Net Multiple Personality Disorder), and we can't keep track of who we're supposed to be-and when. One name here, another there. Trying to keep track of passwords and rules when all we really want to do is book a hotel, get the latest Grisham novel, and check on the ever-dwindling levels of a 401k account. There are a few things Web users, including me, covet in a Web experience. First, we want a secure Web, particularly if personal information is going to be involved in any way. And a critical aspect of that security must be simplicity. If not, we'll create all kinds of work-arounds that end up weakening, or defeating, the very security that we so desire. Second, Net users want privacy. We want to be able to browse in peace, knowing that there isn't some "Big Brother" out there, tracking our every click and browse. If a centralized service is used for Net identity management, it becomes a huge temptation to capture and profit from all that data to which only we should be privy. Big Brother watches our Net habits, captures our clicks, and sells that info, 'cuz the most likely Big Brothers of the 21st century are capitalists. Finally, Net users want a sense of control. We should decide what information to provide and share, for each of our Net IDs. Maybe we want to manage multiple IDs centrally, maybe not. The point is, we decide. And that comfortable feeling of control isn't going to happen until we have some control over the process-and some control over where our data goes.
Freedom Through Federation
You may remember in 1999 at BrainShare, the annual Novell technology conference, when Novell unveiled a new identity solution known as DigitalMe. The idea was to give users the ability to regain control over their Net information. DigitalMe was an exciting and forward-looking concept. Four years later, with standards-based solutions and broad industry support, Novell continues to lead the way with both standards involvement and real solutions.
DigitalMe was a first step toward a broader identity concept known as federated identity: the ability to create and manage identity information in a distributed fashion (See Figure 1). Different accounts may hold different types of information, as appropriate to each account's purpose, but each may be linked to provide single sign-on, and greatly simplify the user experience. Consider the following:
Federated IDs eliminate the need for a monolithic, centralized identity service for single sign-on. That means one less place for Big Brother to hide.
The links between a user's various Net identities are configured and managed by the user and not an external entity.
Because identity information is distributed, there is no single point from which all user information can be accessed, observed or stolen.
Figure 1
The technologies and standards are quickly forming to achieve these goals, and Novell is front and center in helping to define the standards, and build the Net services that will make federated identity a reality. So if the idea of taking control of your Net identity, and actually achieving single sign-on on the Web is appealing, follow the four easy steps to achieve freedom for your Net identity that are outlined below. Well, maybe it's not all that easy, but who ever said that freedom was free?
Step One-The Protocol
The first piece needed for the federated identity puzzle is a standard way of communicating identity information so that Web sites will be able to perform background authentication operations as part of the single sign-on process. And the Security Assertions Markup Language (SAML) fits this need to a tee!
SAML (http://www.oasis-open.org) is an XML-based framework for exchanging authentication and authorization information. Developed and managed by OASIS (Organization for the Advancement of Structured Information Standards), SAML provides a key to simplifying Net identity management through single sign-on.
With SAML, authentication information provided at one Web site can be leveraged to provide authentication to other Web sites that have a relationship with the authenticating site. This would be particularly relevant in building affinity groups. For example, logging into an airline Web site lets a user seamlessly access hotel and car rental sites that have an established relationship with the airline.
SAML relies on the concepts of "subjects" and "assertions." Subjects are any identifiable entity and the source of the assertions. Assertions are essentially claims that the subject makes about their rights and privileges at the target system. Assertions are accepted or rejected based on the information provided by the authenticating system. Assertions come in three flavors:
Authentication: Indicates that the user has been authenticated by some system. That authentication may have been a password, PKI certificate, smart card or any other authentication method. The specifics of the authentication process used would be agreed upon by the participating entities. So, from our airline example, once you have authenticated to your airline's frequent flyer site you are transparently authenticated to the Web sites of participating services partners, such as car rental and hotel reservation sites, that you choose to visit.
Authorization: Defines the resource set to which the subject should be granted, or denied, access once an authentication has occurred. For example, your authorization as a "million miler" on the airline's Web site grants you access to special promotions and discounts on the Web sites of the airline's service partners.
Attribution: Provides attributes, or bits of data, which are related to the subject and which are transferable between systems. Attributes could include music preferences, dietary considerations, smoking/non-smoking or airline seating preferences. So, relevant portions of your airline profile information can, with your permission, be seamlessly provided to the airline's service partners to create dynamic customized offerings for your specific requirements, needs and preferences.
Two methods are used to transmit assertions between the authenticating system and the target system:
Browser/Post: In this method, when a user accesses a target system, the authenticating system generates an HTML form with the appropriate user assertions and passes it back to the user's browser. The browser then posts the form to the target system where the assertions can be reviewed. Based on the assertions provided, access is either granted or denied the user. (See Figure 1.)
Browser/Artifact: In this method, when a user accesses a target system, the authenticating system generates an HTTP redirect that transfers the user to the target system. As part of the redirect URL, the authenticating system includes an "artifact" that points the target system to the location of the user's assertions on the authenticating system. The target system then retrieves the assertions directly from the authenticating system, and based on those assertions, access is either granted or denied the user. (See Figure 2.)
Figure 2
Challenges to Federated ID Implementation
You may be wondering about a couple of issues as you ponder the potential of federated identities:
Business Relationships: You may have noticed that a key facet of the federated identity infrastructure revolves around the creation of circles of trust between organizations. There's no silver bullet here. The only way to create these relationships is the old-fashioned way, and that means lawyers. Robert Frost said that good fences make good neighbors, and business relationships are created through contractual "fences." These contracts will identify each party's responsibilities and the consequences of failing to live up to those responsibilities.
Because any lawyer, quite rightly, is going to approach the relationship from the perspective of the worst-case scenario, hammering out all the details associated with this type of agreement could take some time. Multiply that process by even a few organizations and your circle of trust could take a while to build. The key qualities that will get the job done are persistence and patience. The value is relatively easy to quantify; the hard part is getting the commitment to pursue that value even if the road is long and potentially bumpy.
Microsoft Passport: Although born out of rivalry, Microsoft Passport and Liberty Alliance could likely end up working together in the federated identity world of the future. Obviously, Passport is a de facto standard simply because it is Microsoft's. However, Microsoft has announced that it will provide SAML support in its next release of Passport, paving the way for interaction between the two standards.
From the Liberty Alliance perspective, this could mean that Passport could be treated like any other authentication type. Under that model, an IdP could identify subjects authenticated through Passport, and SPs could decide whether or not to accept the subject's assertions. Bottom line, if all involved can keep their eye on the ball (federated identity services) we stand a decent chance of seeing a robust infrastructure develop over time.
The catch to using SAML is that it doesn't specify the level of confidence that should be applied to an assertion. It doesn't tell you how to develop confidence in the entity from which you are receiving the subject assertions. The reason is that the level of confidence given to any assertion is directly proportional to the relationship that has been developed with the provider of the assertion. It has nothing to do with technology and everything to do with good old business. Negotiations, agreements and contracts-all the regular stuff of business-must still occur on the back-end before using SAML becomes a practical possibility.
Step Two-The Alliance
So we now have the technological capabilities necessary to deliver single sign-on and a simplified user experience on the Web. That's the easy part. Now comes the hard work of creating the network of business relationships necessary to support the technology. Bringing together diverse business interests and involving them in the process is crucial, and that is just what Novell is helping to accomplish through its participation in the Liberty Alliance Project (www.projectliberty.org).
In the words of the Alliance, "the role of the Liberty Alliance Project in all of this is to support the development, deployment and evolution of an open, interoperable standard for federated network identity."
The Liberty Alliance Project, or simply the Liberty Alliance, is developing standards that leverage SAML to create a structured and formal way of managing federated identity on the Net. The Liberty Alliance specification puts a wrapper on SAML that constrains the use of the protocol to make it more effective to a federated identity application. By pursuing these goals within a broad forum of over 160 organizations-and growing-Liberty Alliance is also becoming a test bed for developing the relationships necessary to support federated identity.
Liberty Alliance has five key objectives that it has articulated in the development of the Liberty Alliance specification:
Provide Single Sign-on: Provide an open, single-sign-on specification capable of supporting multiple, independent providers of identity information to promote the goal of federated identity.
Enhance Constituent Relationships: Enable all types of organizations to control, manage and improve relationships with constituents.
Support All Devices: Develop a network identity infrastructure capable of supporting current and emerging network access devices.
Enable Consumer Privacy: Strengthen the abilities of all types of organizations to protect consumer privacy, as well as enhance the protection of organizational and business data.
Support Interoperability: Provide an open framework that encourages interoperability with existing systems, standards and protocols.
To accomplish these goals, Liberty Alliance embraces the federated identity model in which there is no centralized identity provider. Currently in phase one with phase two due in the Fall, the Liberty Alliance specification allows organizations to form alliances and link their service offerings in a complementary way that is useful to their collective constituency. These organizations create authentication domains, or "circles of trust," within which users can move seamlessly from one site to another without having to reauthenticate.
But don't think this puts the power in the hands of the organization. The beauty of Liberty Alliance is that it doesn't leave the user out of the equation. When a user authenticates to a Liberty-enabled site, they can choose to link their existing site identity with their federated Liberty identity. Once linked, subsequent visits to the site no longer require the user to log in because the site recognizes the user by way of their Liberty identity. The key is that the user chooses whether or not to create the federated link, not some centralized identity service looking to corner the market on Internet user data.
Liberty Alliance Phase Two
On April 15, the Liberty Alliance released a draft of its Phase 2 specification. It will be open for study and comment throughout the summer, and a ratified version is expected sometime in Fall 2003. Phase 2 focuses on extending the federated identity capabilities first introduced with Phase 1 in 2002. Additionally, Liberty Alliance is starting to produce best-practices documents that help organizations understand how to develop federated identity infrastructures, including the allimportant circles of trust.
Phase 2 provides three new elements to the Liberty Alliance specification:
Liberty Identity Federation Framework (ID-FF) v1.2: This standard further extends the features in Phase 1 by providing:
Enhanced affiliation options that let a user link to groups of affiliated sites
Ability to perform certain types of requests anonymously
Liberty Identity Web Services Framework (ID-WSF): This new standard provides the components necessary to build interoperable identity-based Web services, including Permissions-Based Attribute Sharing, Identity Discovery Services, and an Interaction Service that allows third-party sharing of attributes with the user's permission.
Liberty Identity Service Interface Specifications (ID-SIS): This new standard provides the first set of standardized templates for sharing basic identity profile information. This provides a common language for interoperable Web services based on ID-WSF (mentioned above).
To accomplish the integration described above, the Liberty Alliance specification relies on a few primary concepts (see Figure 3):
Pseudonym: This is a random identifier used as a key to the federated authentication process. The Liberty specification leverages SAML's Browser/Artifact assertion transmission, using the pseudonym as the artifact. A user will have a different pseudonym for each Liberty-enabled Web site to which they authenticate. This helps protect user privacy by making it very difficult to track identity movement from one Web site to another.
Identity Provider (IDP): The Identity Provider is the starting point for the federated authentication process. IdPs are typically those interested in creating a circle of trust with other organizations. This might include an employer that wants to link external sites of interest for easier employee access; or an airline that wants to create an affinity group including hotels, car rentals, etc., so that customers can have comprehensive and seamless trip-planning capabilities. The IdP maintains a list of all pseudonyms associated with a given user.
Service Provider (SP): Service providers are organizations offering Web-based services to users, and could include most any organization on the Web. An SP maintains one, and only one, pseudonym for each user. During Liberty authentication, the IdP to which the user has already authenticated will transparently pass the user's pseudonym to the SP in order to authenticate them automatically.
Figure 3
The same organization may function as both an IdP and an SP, depending on the nature of the interaction. The ability to perform the Liberty authentication is dependent only upon organizations deploying IdP and/or SP products in their Net infrastructures. Users don't have to do anything beyond using a standard Web browser.
The overall layout hasn't changed too much, and is still comfortably familiar to GroupWise veterans.
Effectively, the Liberty Alliance creates an authentication-sharing infrastructure that is easy for the user and does not require wholesale changes to existing identification systems. Users will still create accounts at each site, and will still need to follow the name and password rules in order to do so. However, once a site is Liberty-enabled, all that complexity is removed in favor of a single authentication sequence and background communications that accompany the user as he or she moves from one Liberty-enabled site to another.
Step Three-The Solutions
As the world leader in identity management solutions, the pursuit of a federated identity for the Net is a natural fit for Novell. After all, organizations already use the industry-leading Novell eDirectory to manage well over one billion identities all over the world. Now, Novell offers two federated identity solutions. The one you choose depends on your focus and specific needs. Novell's leadership will provide businesses with the tools to start implementing user-based permission controls for identity sharing, and accelerate creation of the circles of trust necessary to put the protocols and specifications to practical use.
The SAML extension for Novell iChain, released in June 2003, (www.novell.com/samldownload) is a free download to iChain customers. It allows businesses to leverage SAML to securely share authentication and user attribute information with partners and suppliers across the Net. By leveraging the iChain proxybased architecture, organizations can deploy SAML-enabled services without having to make any changes to their existing Web infrastructure.
SAML for iChain offers a flexible, federated identity service that can be fine-tuned to the needs of specific business relationships. The result is a single sign-on solution that can span geographical and organizational boundaries to provide a set of personalized services, seamlessly integrating offerings from multiple locations or organizations.
The Liberty Identity Provider for Novell eDirectory (www.novell.com/liberty) is also a free download. It lets Novell eDirectory customers leverage their existing investment to provide enhanced identity services. As a member of the Liberty Alliance management board, Novell is helping to drive the development of the Liberty specification. It is also one of the first vendors to offer federated identity solutions. The IdP for eDirectory is part of the Novell Nsure secure identity management solution group, and is based on the Liberty Alliance specification v1.1.
IdP for eDirectory actually provides organizations a way to implement a federated identity strategy without losing control of valuable user information. Data such as buying habits, purchase history and shopping preferences-so necessary to personalizing the online experience and improving customer retention-can easily be lost through the use of a single sign-on solution leveraging a centralized external identity service.
More important, IdP for eDirectory lets you make it fast, easy and economical for customers to leverage on-line services. This will lead to expanded use as users' Gordian knot of Web identities is finally parted resulting in new revenue and cost-saving opportunities.
Step Four-Reap The Benefits
Regardless of the Novell federated identity solution you decide to use, remember that the benefits of these solutions are not confined to Business to Consumer (B2C) environments. Modern organizations face nearly all of the same issues in managing the identities of its employees-Business to Employee (B2E), and its relationships with external partners and suppliers-Business to Business (B2B.)
With IdP for eDirectory, organizations can create their own circles of trust with business partners, suppliers and other external entities. Employee health care providers, 401k management and brokerage houses for shareholder services can be linked into a seamless "self-service" environment for the employee without requiring the organization to be in the middle of everything. After all, once my company makes the matching funds contribution to my 401k, I would rather they have nothing further to do with my investment options. Remember Enron?
Imagine a B2B environment in which employees, once authenticated to their company's network, can seamlessly move to a business partner's or supplier's Web services infrastructure in order to check on the status of a pending order. SAML extensions for iChain make it possible to create just such a linked Web infrastructure with a minimally intrusive solution that is quick and easy to install, configure and use.
And did I mention that both the Novell federated identity solutions are free? That's right. You can start to develop a federated identity infrastructure with no additional costs beyond existing eDirectory or iChain investments.
With the Novell federated identity offerings, it's now possible to create a secure, federated identity infrastructure that provides users with a simplified, seamless Net experience without sacrificing control over their personal Net data. In fact, you can actually enhance Net privacy! Novell solutions are standardsbased, eliminate the need for a centralized Big Brother and are available today. Not only that, but Novell's unparalleled leadership in the identity management and directory space means that your Novell federated identity solutions are built on nearly 15 years of unmatched identity experience.
That's the vision Novell has been providing to the industry for years, and now that vision provides Net users liberty from the fear of unchecked information sharing! Liberty from the tangled mess of multiple Net identities, rules and passwords! Liberty from the shadow of Big Brother and his peering eyes! Give me Liberty or give me death? No! Give me Liberty, AND give me death... death to Net complexity and confusion. Novell can help you make it happen. Sounds like Novell is speaking your language.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.