eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
These days, an increasing number of my friends are looking for Valentines online. Unfortunately, its all too common for people to pretend to be someone theyre not. Or at least, stretch the truth. Too often SWM with George Clooney looks, future CIO, turns out to be SWM with George Costanza looks and a help desk job.
Identity problems, unfortunately, are even more complex in the world of enterprise computing. As Web services move from early adoption to mainstream acceptance and migrate outside of the safety of enterprise firewalls, an increasing number of organizations are faced with the task of ensuring users are who they say they are. On top of that, these enterprises are also working to authenticate users not just for one application, but a slew of them.
Single sign-on has long been the Holy Grail in identity management. The ability to eliminate the need for users to manually enter a different username and password to gain access to applications—or, in the case of consumers, e-commerce sites–would not only lower help desk requests but also provide a more rewarding user experience.
But to date, single sign on implementations have been few and far between. The main culprit: The lack of interoperability between proprietary technologies from different vendors.
Earlier this month, however, The Liberty Alliance Project released a new specification that details how its federated identity model might be deployed to work with third-party single sign-on systems including Microsofts Passport and other identity management systems such as Verified by Visa. The technical white paper, Identity Systems and Liberty Specification version 1.1. Interoperability, also explains how Liberty can also be used by organizations to provide user authentication.
The Liberty Alliance supports the Secure Access Markup Language (SAML), which makes use of authentication tokens exchanged between remote sites and applications, while Passport has a proprietary schema. The two systems differ in the way they communicate the token from site to site. The paper proposes scenarios in which a third-party Web site might act as a mediator between Liberty and Passport domains, converting Passport tokens into SAML assertions and vice versa.
While most of the integration work would fall upon third party vendors, the move is still good news for IT managers reluctant to deploy multiple authentication systems to support both Liberty and Passport users. Whether or not Passport and Liberty are meant to be together, however, still remains to be seen.
How will you handle identity management for Web Services? Write to me at [email protected].