Safety in numbers

WHO YOU ARE, what you’re allowed to see, and how much you can spend: That’s what identity management is supposed to take care of. Although the idea of a monolithic ID management scheme appeals to some — even the most paranoid can see the advantages when compared to trying to memorize dozens of site-specific credential sets — few IT shops are swallowing the bait. It appears that ID management isn’t going to happen the way Microsoft’s shills and others thought it would; instead of the highly centralized vision made manifest by Passport and the early slide shows that described .Net My Services, corporate IT seems to prefer the traditional “local control” approach to user authentication.

End-users also appear less than eager to turn over their identities to a monolithic data repository. Some figures released by Gartner earlier this year indicate that outside of captive Microsoft services such as Hotmail, MSDN (Microsoft Developer Network), and Windows Messenger, Passport is a flop. For some reason, people are reluctant to entrust their digital IDs to a company whose products require patching on a weekly basis. But will users Joe and Jane — or for that matter, IT directors Amy and Andy — be able to turn to an alternative soon? This is the $64 billion question, the answer to which will ultimately determine the future of Web services.

Instead of using a central repository, which brings with it all kinds of privacy and security baggage, successful ID management schemes will use a “federated” model that pulls together data from sources as required by the client’s software. The Liberty Alliance has taken the federated approach from its outset, attempting to provide an alternative to the more centralized Passport model put forth by Microsoft last year. But loose allegiances between principals can undermine the goals of a federation, and Liberty may prove to be no exception to this rule. Agreeing on the specification is the easy part; whether or not we see members open up their products for the sake of interoperability is another thing entirely. If nothing else, it will take a couple of revision cycles.

Fumbling toward federation

Take the question of directory services. No matter what you want to dress it up as, the core of identity management is the directory service. Directory services have been widely used in corporate IT for more than a decade, evolving from the primitive methods used in DNS (Domain Name Service) and NIS (Network Information Service) to increasingly sophisticated offerings including LDAP (Lightweight Directory Access Protocol) products and Novell’s NDS eDirectory.

With that essential ingredient in mind, herein lies the rub: Liberty’s main promoter, Sun, has its own directory services product line to push. The problem that many customers are likely to find with the Sun ONE (Open Net Environment) suite is its uneven platform support from one element to the next. For example, whereas the core Sun ONE directory server runs on a wide range of servers, its metadirectory software runs only on Solaris 8 and Windows NT 4. Some of the smaller fry in the Liberty aquarium have similar problems in that their products often address one part of the identity management puzzle very well and other parts poorly, if at all.

What is a challenge for some becomes an opportunity for others, and we expect that consultants will ring up a lot of hours making disparate services talk to one another, even with the common ground provided by LDAP, XML, and the XML derivative SAML (Security Assertion Markup Language). Although SAML is still in its infancy — its first public presentation is expected this week at The Burton Group’s Catalyst 2002 conference in San Francisco (see “SAML frames ID debate,” page 23 ) — it will influence, if not drive, the emerging identity management market.

But there’s something even more important than SAML, and that’s the opportunity for the emergence of a true standard for Web services security, WS-Security, as posited by IBM, Microsoft, and VeriSign. SAML and WS-Security are complementary specifications; perhaps the easiest way to keep these straight is to remember that SAML documents contain the authentication information, whereas WS-Security dictates how the SAML document is presented as part of a SOAP conversation.

Interestingly, Sun recently endorsed WS-Security, which includes identity management and is currently before the Organization for Advancement of Structured Information Standards. We expect that Liberty will incorporate WS-Security under its own specifications. Although the initial SAML implementation was designed with SOAP (Simple Object Access Protocol) in mind, SAML authors, which include heavyweights such as Baltimore Technologies, Novell, and RSA, have a WS-Security-compliant model under way.

As specifications and standards shake out, the rumblings we are hearing from developers and IT managers tell us that for the next year or two most implementations of secure Web services will occur on corporate intranets inside the firewall rather than on the Web. This makes good sense from a number of angles, particularly when standards are as immature as SAML and WS-Security. It’s a lot easier to retool a less-than-successful project when it’s not in the public eye.

If Web services are going to succeed, successful and secure identity management is a prerequisite. Whether the authentication takes place using certificates, PKI (public key infrastructure), or good old-fashioned user IDs and passwords, it will have to occur more or less transparently to users and on a site-by-site basis rather than through the maw of a central, monolithic gatekeeper. Despite the fact that emerging and existing standards and specifications promise to simplify matters, it remains to be seen whether or not vendors can play together long enough to make interoperability possible.