Federated Identity Standards: Confused?
Practical implementation of federated identity becomes a question of business drivers. If there is a business imperative to integrate and manage distributed systems of identity, then the enterprise needs to make some hard choices. The safe bet is a vendor that has stated support for all three standards. Nearly all do.
Business is becoming increasingly virtual and decentralized, while real-time relationship management with employees, contractors, partners, suppliers and customers is becoming ever more crucial. Even within a single company, password-protected applications reside on different platforms, in separate departmental security domains, in legacy databases derived from prior acquisitions or (thanks to outsourcing) in separate companies around the world.
As gaining access to distributed resources becomes increasingly vital, the ability to manage identity effectively becomes a paramount concern. Federated identity is a set of mechanisms through which companies can share identity information between secure networks. As a result of federation, companies can create identity-based applications -- such as a federated single sign-on -- that enable increased access to cross-company information.
Federated identity offers several compelling benefits to organizations. Federation means that local identities and their associated data stay in place, but they are linked together through higher-level mechanisms. Also, the federated identity strategy can help organize controlled links among distributed user identities. This allows for efficient management, control and movement of user IDs in a radically distributed world. And as organizations integrate more tightly with trading partners and outsourcers, federated identity can provide a flexible mechanism to authenticate users from partner organizations and provide them with seamless access to protected online resources.
But federated identity and the standards surrounding it can be very confusing. From Liberty to SAML and sea to shining sea, federation has become a bit of a tangle. The purpose of this article is to sort through some of the acronym jungle.
Federated Identity Standards: In the Beginning
The move toward federated identity standards began because enterprise identity management companies started to ask how they could obtain single sign-on usernames to and from their partner organizations. The fact that vendors could not ensure their own systems would achieve universal deployment led those vendors to realize that the ultimate solution to this problem was not one-off integration, but rather a standard mechanism for single sign-on that could be adopted by many organizations to provide this capability to users.
The quest for developing a single standard began with a company named Securant. Securant, along with its identity-management platform, ClearTrust, was later sold to RSA Security. Securant worked for several months -- with a few dozen of its customers, partners and other vendors -- to create a standard called AuthXML. A few days after AuthXML was publicly announced, Netegrity and VeriSign announced their own standardization effort for the same problem: S2ML. Through the encouragement of customers and analysts, the parties involved decided it would be best if the efforts were combined.
During this time, a couple of meetings were held with representatives of all of the leading Web access control vendors -- about 10 of them. Ultimately, the representatives decided to join the two standards efforts at the OASIS standards organization. All of the members of the group joined OASIS to work on the new standard, which took its name from the two standards it was based on: the Security Assertion Markup Language, or SAML. That work resulted in the SAML specification's release on January 9, 2001.
From SAML to Liberty to WS Federation
The Liberty Alliance, a consortium of technology vendors and end-user companies, formed to provide an open standard for federated identity. Liberty's work sought to build upon SAML to provide, in essence, an extension that more tightly defined the broad-based work SAML had started. In so doing, Liberty also incorporated the WS-Security specification that Microsoft, IBM and others had submitted to the OASIS body. Of course, the story doesn't end there.
Microsoft, IBM, VeriSign and others united to write a broad set of specifications under the WS label. The companies intended this body of work to be a more modular architecture than other federated identity specifications -- primarily because the WS work is meant to include other Web services needs. Accordingly, one can find WS-Security, Policy, Trust, Secure Conversation and WS-Federation -- where federation is one member of a larger family.
This tangle of standards and dependencies leads us to a brief explanation of the federated identity standards universe.
The Universe of Federated Identity
The universe of federated identity has come to encompass much more than simply single sign-on. Groups like the Liberty Alliance and the vendors focused on the WS-Federation specifications have begun to work on attribute exchange and associated services.
Figure 1 outlines the standards and dependencies as they exist today. A brief explanation of each follows.
Confused? Of course you are -- that's why this article exists. To sort this out, let's deal with the universe of federation standards as they exist today. That leaves us with SAML 1.1 (which is not backward compatible with SAML 1.0), Liberty 1.1 and Liberty Phase 2 (ID-FF 1.2 and WS-F -- all of which are backward compatible with Liberty 1.1).
Given all of the above, the distinguishing factor is simple: If you are an enterprise that is seeking to link to preexisting accounts, and you must do so before 2005, then your easiest path is to use the Liberty Alliance specifications.
The reason for the above statement is simple. While SAML 1.1 will allow you to perform the same operations, it will require you to extend the profiles to do so. The Liberty Alliance -- in its current form -- is built to accomplish this operation. That said, all of this will change as SAML 2.0 is released. Realistically, it should ship in products in the 2005 time frame. SAML 2.0 will incorporate Liberty 1.2.
The Future of Federated Identity Standards
The one question that surfaces time and time again is around convergence. Will there be a convergence of federated identity standards? Hopefully, this article has shined some light on that conundrum. SAML and Liberty increasingly are becoming intertwined. WS-Federation (and the supporting specifications) stands apart. Broadly speaking, then, federated identity sits in two camps: the SAML/Liberty camp and the WS-Federation camp. Of course, some vendors are planning to incorporate all standards.
In the meantime, practical implementation of federated identity becomes a question of business drivers. If there is a business imperative to integrate and manage distributed systems of identity -- and that business imperative demands some near-term action -- then the enterprise needs to make some hard choices. The safe bet is a vendor that has stated support for all three standards. Nearly all do.
The implementation choices most likely will come down to the use case -- and if that use case is about linking two preexisting accounts, then the Liberty Alliance presents the easiest path.
Eric Norlin is senior vice president of strategic marketing for Ping Identity Corporation and contributing editor for Digital ID World.
Darren Platt is director of solutions architecture for Ping Identity Corporation. His previous positions include vice president of engineering for Securant and founding member of the SAML technical committee.