ACS Rule Groups and Service Identities

In my previous post I walked you through configuring ACS to issue SWT tokens to a client using Service Identities and when it came to configuring the Rule Groups we just left everything as default. I just wanted to expand on this area a little bit as the Rule Group can be very useful when it comes to securing a Relying Party with a Service Identity.

Restricting access

By accepting the defaults when creating the rule group we are essentially telling ACS that we accept ANY Service Identity credentials as valid for the relying party and to just pass on the claims that ACS produces. But what if we want to restrict which Service Identities can authenticate with ACS? Well it's actually very simple, we modify the rule!

By selecting an Input claim type of nameidentifier we are able to instruct ACS to only run this rule when a matching claim and value is found. When authenticating with a Service Identity, ACS will create a nameidentifier claim with the value set to the Service Identity name. We can specify this as our claim value in this rule.

The rule then tells ACS to output the same nameidentifier claim with the same value, effectively passing it through. Of course we could set this up to output a completely different claim and value but for now this is all we need to do. The output claim will then be wrapped up into the SWT token and sent back to the client.

This rule effectively restricts access to the relying party by only accepting the Service Identity matching the claim value.

I can test this by trying to authenticate with the 'RESTClient' service identity which should succeed based on my rule and then using the 'two10na' Service Identity which should fail.

First using 'RESTClient'

This results in a successful response:

Now let's try it using 'two10na':

Access denied! We get a 403 (forbidden) back from ACS because it is unable to successfully run the Rule Group associated with the Relying Party.