After months of agonizing wait, the Liberty Alliance has finally revealed phase one of its technical specifications for its single sign-on (SSO) standard, called the Liberty Alliance V 1.0 specification. The standard is based on the Security Assertion Markup Language 1.0 (SAML), a new proposed standard for interoperability among Web services security products, which works with XML (extensible markup language) and SOAP (simple object access protocol).
The Liberty Alliance was founded by Sun Microsystems Inc. in reaction to Microsoft Corp.'s announcement of its SSO technologies, which include Passport. There was a fear within the industry that Microsoft would become the tollgate keeper for online transactions should Passport become the dominant online identity technology.
Liberty Alliance members include diverse organizations such as American Express, General Motors, MasterCard International, Nokia and NTT DoCoMo.
SAML 1.0, which is to be ratified by the Organization for the Advancement of Structured Information Standards (OASIS) by November, defines SOAP-based interactions among security and policy domains and supports Web SSO, authentication and authorization. The standard defines request and response "assertion" messages that security domains exchange to vouch for authentication decisions, authorization decisions, and attributes that pertain to named users and resources.
SAML 1.0 also defines functional entities such as authentication authorities, attribute authorities, policy decision points and policy enforcement points.
In a SAML-enabled Web SSO scenario, users log on to their home or "source" domains through authentication techniques such as ID and password. The source domain communicates this authentication decision, plus other information that provides a security context for that decision, to one or more affiliated or federated destination domains through messages that contain SAML "authentication assertions" and "attribute assertions."
However, the objective of the Liberty Alliance V 1.0 specification is actually broader than single sign-on. According to Neil Macehiter, senior consultant, Ovum, the significant issue is that it is providing single sign-on based on federated identities.
In a federated identity model, identity information is shared between service providers which offer Web-based services, and identity providers which establish business relationships with service providers such that the user can share his or her identity with the service providers. Examples of service providers include portals and business-to-consumer sites, whilst examples of identity providers include banks and enterprises. In this scenario, users, identity providers and service providers operate in a circle of trust.
While it continues to gain marketplace traction, SAML 1.0 is still a new specification whose long-term viability remains unproven. The true test of SAML 1.0, as of any standard, will be in how well the market accepts the proposed standard and enables development of Web services through products that support it. Web security vendors are hard at work ironing out the myriad technical details necessary to support interoperability among their diverse SAML 1.0 implementations.
There was consensus among the members of the Liberty Alliance that the technical specifications will, as far as possible, be based on existing standards, noted Justin Taylor, chief strategist, Directory Services, Novell. Novell contributed its expertise in directory and protocol services to the alliance.
According to Macehiter, single sign-on is concerned with the mechanisms which service providers and identity providers use to convey information (asserts) to one another and not the mechanism by which the user is authenticated. Liberty V 1.0 therefore supports a variety of authentication mechanisms, including username and password, and Kerberos. The Liberty specification defines a number of examples to assist service providers in assessing authentication assertions such as authentication based on smart cards or password over SSL.
With the launch of Liberty V 1.0, the Liberty Alliance will be starting on phase two development of its specifications. "The Liberty Alliance will leverage Liberty V 1.0 and expand it to include features for permission-based attribute sharing," said KB Png, director and chief technology officer, Asia South, Sun Microsystems. "This will extend the simplified sign-on capabilities in V 1.0 and enable organizations to share certain personal information of users according to the permissions and preferences granted by the user."
The Alliance also anticipates that the next set of specifications will enable organizations to link and extend their service offerings between various "circles of trust" or industries.
The latest announcements are part of a running battle between the Microsoft and Liberty Alliance camps to establish a single authentication standard, with SAML becoming part of Liberty, and Microsoft's Passport evolving from Kerberos.
Interestingly, after Liberty V 1.0 was announced, Microsoft indicated that it will be supporting SAML under its own vision for federated security. Under the Microsoft's WS-Security paradigm, it will support SAML, X.509 certificates and Kerberos. Like SAML, WS-Security has been given to OASIS for administration. Incidentally, Sun has also recently endorsed the WS-Security specification.
There are still reservations in certain quarters due to the fact that Microsoft's implementation of SAML will not be in its entirety. Parts of SAML that will not be supported include Artifact Profile and Direct SOAP Bindings.
The unveiling of the Liberty Alliance specifications itself came after Microsoft's announcement of a deal with Arcot Systems to enable users of its system to make online transactions using Visa and MasterCard, both of which are Liberty Alliance members.
In April, Microsoft introduced its TrustBridge software based on Kerberos Version 5, a standard authentication technology supported in Microsoft's Active Directory and WS-Security. WS-Security is a proposed Web services security specification also based on SOAP, which was introduced by Microsoft, IBM and VeriSign.
Microsoft's TrustBridge software is designed to help companies share information easily and safely with trading partners and customers. TrustBridge would let an end user be authenticated on his company's network and carry that authentication to other companies' networks to access resources such as Web services.
However, a major limitation is that it works only between companies running Microsoft's Active Directory or between Active Directory and Kerberos 5 Key Distribution Center (KDC) servers.
In addition to that, even though Kerberos support seems to move TrustBridge away from a proprietary Microsoft technology, there have been ongoing problems integrating Unix-based Kerberos services with Microsoft's implementation of Kerberos 5.
According to Bruce Schneier, chief technology officer of Counterpane Internet Security, the incompatibility has to do with something called the "data authorization field" in the Kerberos messages. All major Kerberos implementations leave the field blank. The new Microsoft implementation uses the field to exchange access privileges between the Kerberos server and the client. His fear is that the slight change in protocol by Microsoft would break the security of Kerberos.
For Microsoft, there are already 165 million registered Passport accounts worldwide. Passport is a server-based e-wallet service that includes SSO and one-click shopping services. However, according to Avivah Litan from Gartner, this huge number is a result of Microsoft's huge presence in the market and hides a much gloomier picture of slow consumer adoption, with users automatically registered for Passport without realizing that they are registered.
According to a Gartner survey in August, only 30 percent of the registered users are aware that they are on Passport.