At the same time, all the Liberty Alliance seemed capable of producing was press releases. Open standards for Web SSO looked like a distant possibility at best.
But since July, Microsoft has announced that the next version of Passport will support SAML (albeit, in typical Microsoft fashion, a slightly adulterated version of it), Liberty has released a formal 1.0 spec also based on SAML (Security Assertion Markup Language), Sun has shipped a Liberty test kit for early adopters, and a growing list of vendors have announced support for various parts of the growing acronym soup of SSO technologies. The upshot is that interoperability between SSO networks, including Passport and Liberty, will come to pass, slowly and awkwardly, but almost certainly.
That means it's time for potential users of SSO technology to start getting their hands dirty. A slew of recently announced products are meant to help intrepid IT managers face the task.
But before looking at single sign-on products, an organization has to look at what technologies it's already using to store and control user information. Most SSO tools integrate with existing directory products to store user information, including LDAP (Lightweight Directory Access Protocol), Active Directory, and Novell eDirectory. Also, an organization's development environment--.Net or J2EE--will play a role in which products an organization considers.
Web SSO is only a part of the authentication and authorization puzzle, and IT managers need to make sure that SSO products also provide other tangible benefits. Does a product provide a central control point for user identities? Does it need to, and can it, work with other security technologies an organization may already be using behind the firewall, like Kerberos or X.509? Before tackling Web SSO, it makes sense to review the overall user management landscape, and to make sure Web SSO strategies fit in with the larger picture.
Web directory and security firm OpenNetwork first demonstrated Passport interoperating with SAML in July, using their DirectorySmart application. The OpenNetwork demonstration was just that--a demonstration, under controlled circumstances, and not a real-world application. But if the features of DirectorySmart or similar products are able to help with more immediate and real-world issues of user management and authentication right now, then they may make sense as a stepping stone to the use of Web SSO as the technology matures. DirectorySmart integrates with LDAP and Active Directory, provides an API for custom development in COM, C/C++, Java, and, recently, .Net, and also provides connectors to common Web servers and App servers.
New products from Netegrity (SiteMinder and the soon-to-be-released TransactionMinder), Oblix (NetPoint), and Novell (iChain) all provide similar features, and are proven solutions for behind-the-firewall SSO and identity management. All have announced SAML support, meaning that while they can solve today's problems, they can also serving as platforms for experimentation and growth towards tomorrow's federated networks.
Another issue facing those interested in Web SSO is the question of who they plan to integrate with. Understanding the technologies in use or being considered by your partner sites is an important part of the planning process, and should affect your technology decisions.
Lastly, a cautionary note. Web SSO is a moving target, and the standards are immature. Beginning work on an implementation today means accepting the blood, sweat, tears, and increased costs of operating on the bleeding edge. If the potential upside of being early to market eventually outweighs those costs, now may be the time to get started.