Access Control Service - A Simple Scenario
To the already initiated claims disciples, the Access Control Service is a multi-tenant Resource STS. The behavior of each STS is determined by simple rules - the rules control how each STS transforms claims.
To those not already initiated in the claims methodology, the previous definition may seem a bit obtuse. If that's the case, then consider a simple scenario:
Background
Let's say you work for a software vendor (Foo) that sells a web application (how about employee payroll management) to businesses. You have an existing on-premise offering and an existing install base. This version of your software integrates with customer identity providers (e.g. Active Directory, Tivoli, etc.).
Customer administrators can allow other employees access to the payroll system - this is driven by group membership (e.g. Domain Users have access). Internally the application uses a set of pre-defined roles, and assigns permissions based on role membership. As an example, consider the following simple model:
Active Directory Group= HR Payroll --> Application Role = Administrator
Application Role = Administrator --> Permission = CreatePayroll
Application Role = Administrator --> Permission = PrintPayrollChecks
...
This approach is known as Role Bases Access Control (RBAC). It's very simple, powerful, and very common.
Given that Foo's existing offering is on-premise it works well. Initial setup requires some basic plumbing with a single on-premise identity provider and a bit of configuration by the application administrator.
The Winds of Change
Some of your existing customers and many prospects are asking for a hosted / cloud version of your payroll application. As your team considers options, it becomes apparent that a good long term approach is to modify the existing on-premise application to be multi-tenant. Modifying a single tenant application to be multi-tenant isn't a joke, but customers are demanding it, so you proceed.
One of the things your team realizes pretty quickly is that the RBAC model in the on-premise application has to change a bit. The core concept of mapping groups to roles to permissions appears to still be viable, but now there are multiple identity providers. Your application now has to be able to differentiate Bar Corporation Groups from Baz Corporation Groups.
Luckily most of the software vendors that sell identity providers have built versions of their identity providers that will expose groups and other identity attributes outside of the corporate LAN. I believe that Microsoft's offering in this area is outstanding (Geneva Server, Geneva Framework, Microsoft Services Connector and the Federation Gateway - see Kim Cameron's blog for fantastic details). Concretely, this means that the hosted, multi-tenant version of your application can federate with lots of different corporate identity providers.
The Access Control Service
There is still a problem, however. You'll have to add quite a bit of code to your application to accept and parse tokens from these identity providers. To top it off, you'll have to make it pretty flexible and configurable. This is where the Access Control Service shines. In a nutshell, it is a service that simplifies interactions with any standards based identity provider, and allows you to define rules that transform Groups to Application Roles to Application Permissions.
To put it another way, your application won't have to directly interact with any identity providers. It can trust tokens from the Access Control Service. The Access Control Service will handle the gory details of decrypting, verifying and parsing tokens, extracting Groups (or other identity attributes) from tokens, and mapping Groups to Application Roles to Permissions. The end result is a single sign-on experience for your customers, and a simplified code base.
Up next - the common interaction model of the Access Control Service & why claims disciples call it a claims transformer.