Access Control Service - Common Interaction Model

In my previous post I described at a high level a simple scenario that leverages the Access Control Service. Now I'd like to describe the interactions between messaging participants and the .NET Access Control Service.

Recall the scenario: a multi-tenant payroll application is running in the cloud - it uses the Access Control Service to simplify federation with enterprise identity providers and handle RBAC processing.

The interaction pattern for this scenario is shown below.

Step 0

Before using the ACS, the payroll app (called Relying Party in the diagram) must establish a trust with ACS. This is done via a public key certificate exchange. The Relying Party administrator or developer defines or obtains a certificate from the certificate authority of it's choosing, then uploads the public key certificate to ACS.

Step 1

Next, the Relying Party administrator or developer will define access control rules in ACS. As indicated in my earlier post, the content of the rules is up to the administrator or developer. When this step is completed, ACS is setup and ready for use.

Step 2

The requestor sends a request for a token (Request for Security Token or RST) to ACS. An RST almost always contains claims (eg username / password, or another token issued from an identity provider).

Step 3

ACS then checks the claims in the RST. It then uses the input claims to determine the claims that will be sent in the RST response (called RSTR). Consider a simple rule: (Input) Username foo –> (Output) Role Administrator. If the input claim is Username foo, then the output claim is Role Administrator. ACS simply chains these rules together and calculates the output claim set.

Step 4

After the output claim set is determined, the claims are packaged into a SAML token and returned to the requestor. The token is signed with the ACS certificate and encrypted with the certificate used in step 0. There’s a little more to it than that, because the RP has to be able to differentiate its ACS STS from other ACS STSs. This will surely be a subsequent topic.

Step 5

The requestor then sends the token to the Relying Party along with a payload of its choosing.

Step 6

Upon receipt of the token + payload, the Relying Party verifies / validates the token, checks the claims in the token, then processes the payload accordingly. Concretely this means that the Relying Party verifies the token signature & decrypts the token. If the token signature / encryption keys are OK, the Relying Party then checks the claims in the token. If that endpoint or operation on the Relying Party requires Administrative privileges, then the token must contain an Administrator claim. Think of it like a simple toll gate. If the correct claim is present, the call proceeds. If not, then the call fails.

Claims Transformer

At a high level, ACS receives input claims and transforms them into output claims. We simplify these types of transformations into rules, and provide customers the ability to define these rules on a portal or through a simple API.

Comments

• Anonymous
  January 24, 2009
  This blog is way too quite.  I know you have TONS of good things to say, Justin.  Please do; we're listening and we're eager to hear. For instance, I would love to learn more about what happens in step 4 where you say: "There’s a little more to it than that, because the RP has to be able to differentiate its ACS STS from other ACS STSs." That sounds really fascinating.  A blog post on that would be great.