Single sign-on--harder than it sounds
Microsoft Passport is already in place, and because you have to use it with such popular services as MSN Hotmail and MSN Messenger, there are more than 160 million passports in existence. But because you can have multiple passports, there aren't 160 million users. Microsoft also claims that more than 220 Web businesses have already outsourced their authentication requirements to Passport.
Behind the scenes, Microsoft uses a proprietary implementation of the Kerberos Internet authentication standard. Microsoft officials also say, though, that they will adopt the Internet Engineering Task Force Kerberos version 5 definition in their new Federated Password system without Microsoft's current extensions. Microsoft engineers admit that modifying Passport to make it fully compliant will be a big job.
The Federated Passport system will be organized much like the current Passport system is--with the centralized databases running on .NET servers. To protect the privacy of that information, Microsoft will be implementing the World Wide Web Consortium (W3C) Platform for Privacy Preferences Project (P3P) standards. Because the P3P represents only proposed standards and isn't a technology, it's impossible to say exactly what it will look like. But users will have a choice as to how much, or how little, information they'll share from the Passport databases with a particular company. (So if you're a Passport user, you can decide to let, for example, eMusic.com only see your name, address, and Visa number, while Borders sees your name, address, and American Express number.)
Historically, Passport has had problems. Besides being crackable, Passport has had problems with keeping its information accurate and available. The MSN Messenger outages during the past summer were partly Passport problems.
On the other hand, Sun's Liberty Alliance has nothing real on the table. We know that it will use open standards, but we don't even know if these standards will be Kerberos, Security Assertion Markup Language (SAML), or something entirely new. Because the alliance doesn't include either directory developers such as Novell or Critical Path, or enterprise authentication vendors such as Netegrity, Oblix, or Tivoli, I think the Alliance will have to base its technology on existing standards. And if I were a betting man, I'd put my money on Kerberos. Sun also already uses it, and it's the most established of all the authentication protocols.
Regardless of what powers the system, it would not be implemented in centralized databases. Instead, Liberty Alliance spokespeople say it will use a distributed system. We haven't been given any answers yet as to what database management systems would be used, who would host them, or how these databases would be synchronized with each other.
Consulting analyst Michael Sampson, from leading electronic messaging research house Ferris Research, thinks Liberty Alliance will win--despite its vaporware nature. "Large enterprises will be more willing to partner with the Liberty Alliance folks for federated identity, rather than with Microsoft (because) trust of Microsoft as a business partner is low," he says. "Their reputation is seared through continual security strikes against Internet-connected products (that is, IIS, Exchange)." Sampson points out that although Liberty Alliance is "just a concept" today, so is federated Passport.
I don't agree. I don't think either one will be ready for you to use in 2002 for delivering your Web services. I'd need to be a lot more surer than I am now about Microsoft's security before implementing Passport, and I can't get behind a plan that's nothing but hot air. Besides, because both plans are for internal corporate use, too--such as providing directory or Web services--I don't have to just shut down online customer ordering if there's a problem. But I might have to shut down my enterprise network.
More to the point, if I want to deliver Web services or a personalized Web site--for example, Amazon.com's customer pages--I want that first page to be delivered quickly. Despite all the talk about these services, no one has mentioned that because of the databases' size and the need to encrypt and decrypt customer information, these systems will be slow. I don't know about your customers, but my customers might not want to wait for their authentication information to be retrieved from a remote site over a secure socket layer (SSL) connection.
Practically speaking, I think the best combination of site performance, system manageability, and customer satisfaction will come from building good, old-fashioned, local authentication systems like the ones we use now for both internal network uses and to provide customers with Web services and customized pages. We can argue all you want about protecting Internet privacy or whether Federated Passport or Liberty Alliance is better, but to deliver the goods on time, local authentication will work the best.