Anne Thomas Manes is CTO at Systinet. Anne is a participant on standards development efforts at JCP, W3C and UDDI and has published widely on Web services and service-based computing. She can be reached at firstname.lastname@example.org.
How Project Liberty and Passport Fit into Web Services
Identity has been in the news of late. First Microsoft announced that Passport will support federated authentication using Kerberos V5.0, then the following week Sun launched the Liberty Alliance Project with a raft of financial, telco, travel, consumer, and security companies. Lots of folks might be wondering why Sun would want to get into a fray with Microsoft over electronic wallets. Electronic wallets are so consumer oriented. It just seems so far out of Sun's normal playing field. But Identity has huge implications beyond the consumer arena: Identity services play a critical role in the future of Web services.
Identity is the keystone that permits Web services to work together. Today, most Web services work alone, but everyone talks about assembling Web services to create more powerful business services. Web service assembly, though, requires that services share information, particularly once we start adding security to our services.
Consider how most Web services implement security today. Each business that offers a secure Web service maintains a list of authorized users, and each user authenticates himself using a userid/password challenge. When we start assembling Web services, we don't want to force the user to type in a userid and password for every individual Web service involved in the greater business service. And we don't want to force Web service providers to develop point-to-point security connections for each Web service assembly effort. Instead we need a facility that enables single sign-on across any number of Web services operated by any number of businesses.
Making a single sign-on scheme work within an organization can be pretty challenging. Making it work across all organizations will be even harder. But it's not impossible. We just have to convince everyone to use a shared Identity Service.
A shared Identity Service consists of:
- An XML vocabulary that describes the information managed and maintained by the Identity Service
- A set of APIs that clients and services use to access the Identity Service
A user's identity is specified using the Identity vocabulary. An Identity Service allows a user to manage and maintain name and contact information, as well as pointers to other information about the user. At runtime, a Web service can call the Identity service to authenticate the user and to obtain basic contact information. When one Web service calls another Web service, it can pass an Identity token with the request so that the second Web service can transparently authenticate the user, too. From the user's perspective, the Identity Service provides a single sign-on service.
Microsoft Passport is an Identity service. Unfortunately, Microsoft has not published the XML vocabulary for Passport, nor have they published a Web service API that allows any Web service to use Passport to authenticate users. Instead, Microsoft sells those formats and protocols. If you would like to set up a Web service that uses Passport as an Identity Service, you have to license the Passport development kit from Microsoft and pay to access the service at runtime. And in case it isn't clear from some of the recent announcements, only Microsoft can operate a Passport service. When Microsoft announced that they have "opened" Passport by adding support for Kerberos V5.0, what that means is that you will be able to allow Passport to access your internal user management system to retrieve user identity information, assuming, of course, that it supports Kerberos V5.0. (I probably don't need to tell you that Active Directory supports Kerberos V5.0). Keep in mind that although you would be managing and maintaining your own list of authorized users, all identity and authentication requests still need to go through Microsoft's Passport service.
AOL/TimeWarner and Amazon have announced plans to develop their own Identity service, code-named "Magic Carpet". One can assume that AOL and Amazon will also adopt a proprietary stance when it comes to Identity. One can also assume that the formats and protocols used to access Magic Carpet will be different from those used to access Passport. So if you'd like your Web service to be able to authenticate users using either Identity service, you'll need to write two different Identity query modules, and you'll need to pay money to both Microsoft and AOL for the privilege of using their Identity services.
Dealing with two Identity services isn't so bad, but what happens when lots of different groups start trying to get into the game. It would be a lot better if there were standards associated with Identity -- one XML format to represent the information, and one API to access any compliant Identity Service. Then anyone could set up an Identity Service, and all Web services would be able to query any Identity Service, and users would have a wide choice of Identity options. Personally I think I feel much more comfortable giving control of my personal financial information to my bank rather than to Microsoft.
So that's why I'm pleased to see the launch of the Liberty Alliance Project. The Liberty Alliance Project says it intends, and I quote, " to create an open, federated solution for network identity - enabling ubiquitous single sign-on, decentralized authentication and open authorization from any device connected to the Internet". It certainly sounds like what I've been describing. It's gratifying seeing this group of companies working together on such a goal. It would be even more gratifying if companies like IBM, HP, and BEA were part of the Alliance. But we can't have everything. Perhaps they will join in time.
Copyright 2001. Anne Thomas Manes, CTO Systinet. Reprinted by permission.
FOR MORE INFORMATION: