I went to a training last week up at Microsoft on Azure. After chatting with a few of my colleagues after returning, however, I realized that I didn't understand the Access Control Service portion of it well enough to explain it to others. For this reason, I watched Justin Smith's screencast from PDC in which he drills down into the architecture, anatomy, and interaction pattern of the service and its consumers. This talk is very similar to the one he gave up in Redmond last week at the training that I attended. In the video, he says that "The service's sole role in life is to issues tokens. It receives claims, transforms those claims, and then packages them up in tokens and sends them back. That's all it does. Real simple. Claims in; transform; claims out. It's a claims transform." After watching this video and attending the training last week, I can say with confidence that the Access Control Service is
- Not intended to be an identity provider;
- Doesn't require a service registry in order to provide authentication and authorization for services;
- Can be used independently of and without having to take a dependency on the ISB, Workflow Service, and other Azure-related offerings; and
- The Access Control Service is a multi-tenant Resource Security Token Service (R-STS).
This video was very helpful in explaining the common interaction pattern that clients exhibit when communicating with the Access Control Service. I've annotated that one of Justin's slide in the following figure:
To interact with this service, the .NET Services SDK comes with a couple of DLLs dubbed the Geneva framework that make this communication easier. They hide the WS-Trust 1.3 gunk (like dealing with RSTs, RSTRs, etc.). They also include an HTTP module that makes it easier to save tokens in cookies and whatnot when doing ASP.NET development. You can also interact with the STS using any other WS-Trust-1.3-complaint stacks such as WCF (via its wsHttpFederationBinding) among others.
As Vittorio Bertocci recently said at Tech Ed, a claims transformer or R-STS running in the cloud "provides a natural point of trust brokering with customers and partners along with a natural point of authorisation [sic], evaluation and enforcement." I couldn't agree more and believe that the Access Control Service and competing, hosted STSs will be tapped more and more as businesses are forced to solve the complex problem of federated identity.