Federated Identity Standards
Confused? You bet you are
Oct. 1, 2004 12:00 AM
Business is becoming increasingly virtual and decentralized, while real-time management of relationships with employees, contractors, partners, suppliers, and customers is becoming ever more crucial. Even within a single company, applications may reside on different platforms, in separate departmental security domains, in legacy databases derived from prior acquisitions, or (thanks to outsourcing) in separate companies. As gaining access to distributed resources becomes increasingly vital, the ability to manage identity effectively becomes a paramount concern.
Federated identity delivers 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. In addition, federated identity organizes controlled linkages among the distributed identities of a user. This allows for efficient management, control, and movement in a radically distributed world. As organizations integrate more tightly with trading partners and outsourcers, federated identity provides a flexible mechanism that authenticates users from partner organizations and provides them with seamless access to protected online resources.
But federated identity and the standards surrounding it can be very confusing. From Liberty to WS-* to SAML and sea to shining sea, federation has become a bit of a tangle. This article will sort through some of the acronym jungle.
The Beginning of Federated Identity Standards
The quest for developing one standard began with a company named Securant. (Securant and their 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, it was decided that it was best for all involved 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. Ultimately, it was decided to merge the two standards efforts at the OASIS standards organization. All of the members of that group joined OASIS to work on the new standard, which took its name from the two standards it was based on, and was named SAML (the "Security Assertion Markup Language"). Their work resulted in the SAML specification, released on January 9, 2001.
From SAML to Liberty to WS Federation
Microsoft, IBM, VeriSign, and others united to write a broad set of specifications under the "WS" label. This body of work is intended 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
Figure 1 outlines the standards and dependencies that exist today. A brief explanation of each follows.
SAML 1.0, 1.1, and 2.0
Liberty Phase 1 (ID-FF 1.0)
Liberty Phase 2 (ID-FF 1.2)
Liberty Phase 3
WS-Security Extensions (WS-Trust, WS-Policy, WS-Federation)
Given all of the above, the distinguishing factor is simple:
If you are an enterprise that is seeking to link two pre-existing accounts, and you must do so before the end of Q1 2005, then your easiest path is to use the Liberty Alliance specifications.
The reason for this 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 Q2 2005 timeframe), as SAML 2.0 will incorporate Liberty 1.2.
The Future of Federated Identity Standards
In the meantime, the practical implementation of federated identity becomes a question of business drivers. If there is a business imperative to more tightly 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 will most likely come down to the use case - and if that use case is about linking two pre-existing accounts, then the Liberty Alliance presents the easiest path.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week