* Microsoft reveals token-based identity and authorization system
Last week’s Directory Experts Conference was, as usual, a pleasure to attend thanks to the indefatigable work of NetPro’s Gil Kirkpatrick, Christine McDermott and Stella DeJean. CEO Kevin Hickey was once again an affable host.
Last week’s Directory Experts Conference was, as usual, a pleasure to attend thanks to the indefatigable work of NetPro’s Gil Kirkpatrick, Christine McDermott and Stella DeJean. CEO Kevin Hickey was once again an affable host.
As has become traditional, the kickoff keynote address was given by Stuart Kwan, director of program management at Microsoft’s Identity and Access in the Windows Server group. Kwan laid out the roadmap for Active Directory (details in my Wired Windows column in this week’s Network World https://www.nwfusion.com/columnists/2005/032105kearns.html) and Microsoft’s Identity Information Server (MIIS). He also spent a good deal of time describing something called “Claims-Based Access Control” (CBAC) as the mechanism for authorization. This is similar, in some ways, to Role-Based Access Control (RBAC), but also different in many ways.
CBAC is a token-based system, and relies on one or more Security Token Servers (STS) to provide the credentials, or “claims,” needed to access a resource.
In the simplest example, a user trying to submit an order to an order-processing server would query it for the credential/claim it needed. The reply might be that it needs the “purchaser” token (or “claim”), which is available from the Security Token Server identified as STS-A. The client then queries STS-A for a “purchaser” token and either gets one, or learns that in order to do so it must present a Kerberos token available from STS-B. So the client then authenticates to STS-B, collects a Kerberos token, presents this to STS-A, collects a “purchaser” token and presents this to the order processing server and then places the order. And that’s the simple example.
It’s a lot like going to the movies, though. The ticket taker only wants a ticket for the movie showing. He doesn’t care who you are or how it was purchased. The ticket seller probably doesn’t care who you are (but might request data concerning your age) as long as you present valid payment. If you pay with a credit card, the issuing bank doesn’t care what you’re purchasing as long as the bank’s fairly confident you’re the person named on the card.
In other words, it’s a whole series of small, mostly single-action transactions creating a larger “meaningful” experience. At least, that’s one way of looking at it.
Another way is to draw a similarity to the process of renting a car. The rental agent wants both a driver’s license and a credit card. To get the driver’s license you need to go to the department of motor vehicles and have proof of identity such as a birth certificate. To get the certified birth certificate you need to go to the department of vital statistics and prove your identity – such as with a driver’s license. The credit card is issued by your bank and may be tied to your bank account. To open that account, you’ll need identification, such as a passport. To get a passport, you’ll need (in the U.S.) to apply to the Department of State and provide both identification (such as a driver’s license) and proof of citizenship (such as a birth certificate). I’m sure you can see the potential for ending up going around in circles in search of the needed “token.”
Which of these two analogies will come closest to Microsoft’s CBAC scheme is still yet to be known, but my thinking is that the latter case is far more likely than the former. As always, I welcome your thoughts.
