This document sets out to describe a number of missing pieces of the puzzle which, when combined, can help the Kerberos Consortium realize the full potential of Kerberos as an authentication technology for the Web.Personally, I could care less about helping the Kerberos Consortium realize the full potential of Kerberos as an authentication technology for the Web but, for my customers, I am all ears! Some of the highlights that I pulled from the document are listed below - any emphasis is mine.
- Mutual authentication is an essential part of building trust between users and systems, and the lack of mutual authentication in many Web authentication dialogs is the root causes of many security and privacy violations on the Web, such as phishing. Kerberos provides mutual authentication as a normal feature of its protocol operation.
- Kerberos service tickets can be embellished with authorization data describing the privileges accorded to the user. This facility is used extensively by Microsoft's Kerberos implementation to assert a user's authorizations within a data structure called the Privilege Attribute Certificate (PAC).
- ...credentials delegation in Kerberos still remains one of its truly unique properties – no other widely deployed security protocol has the ability to pass credentials between members of a multi-tiered architecture.
- Microsoft's identity provider (which probably won't be available until 2009) will support all four defined methods, including Kerberos.
Enabling Kerberos to play a bigger part in web services makes me salivate. Why? All the work that has been done within the enterprise now can be extended outside the enterprise. That's leverage. Extending Kerberos-based authentication and richer authorization capabilities from your enterprise desktop across the web. I like it.
So far the main organization that has enabled Kerberos to play a bigger part in computing is Microsoft - not MIT. My bets are on Microsoft's Geneva to become the prevalent driver of Kerberos-enabled web services. I am much more interested in enabling my customers to completely harness the power of Active Directory!
P.S. Hats off to the authors for writing their requirements as user stories, which typically appear in "Agile" development frameworks. "We have chosen to describe requirements as user stories in an attempt to make the requirements easier to evaluate from the point of view of the various stakeholders."
Active Directory, authentication, authorization, federation, Geneva, Microsoft, MSFT, QSFT, Quest Software, SAML, STS, Kerberos