Using Claims Authorization Rules in ADFS 2.0

I am willing to bet that 90% of the time you have created claims you never really noticed that there are actually 3 tabs for claims that you can use.


Most of the time, we are just messing with the “Issuance Transform Rules.” When you walk through the “Add a Relying Party” Wizard, you may not notice the claim that gets created automatically in “Issuance Authorization Rules.”

Here is a screen shot of the rule that says “Allow everyone”


If we look at the claim, we can see that it is of type permit and the value it true


You can also create a rule that says “Deny someone with this value of a claim.” For instance, I can add a rule that says “Deny access to this Relying Party if anyone tries to log in and has a claim of type Name with a value that looks like “Andy”


By the way, the =~ syntax is saying If a claim of type Name has a value that matches the regular expression, then issue the claim of type deny with a value of “DenyUsersWithClaim.”

You can also issue a strict deny all by doing a straight deny like this

=> issue(Type = "", Value = "true");

So this is all great but what if you need to combine some of these rules and perhaps make an exception for a handful of users. When I first started messing with this, I figured these authorization claim rules would act like a firewall policy. It would start at the top, and then would act on the first rule that it matched, and then processing would stop. THIS IS NOT THE CASE. What made me really think this was the case was that there is an option to rearrange the order of the claims.


You wish it were so easy!  It turns out that if there is a “Deny” rule that matches a users claim anywhere, it will always win, no matter where on the list it is. So in this case, even though permit all is first, if I have a claim that says my “Name” is “Andy” then I will get a denied access error.

We have to get a little tricky. Lets say we want to deny everyone from a particular Identity Provider except for 3 separate users. How would we go about it. Here is one way.

First, lets figure out an easy way to determine at the claims authorization rule, which IDP the user came from. If you go to “Trust Relationships | Claims Provider Trusts” You will see a trust for Active Directory and any other IDP’s that you have added. For the sake of demonstration, lets say you have one called Contoso.  Right click on the Contoso IDP and select “Edit Claim Rules”

You can add a claim using a custom rule. Choose “Send Claims Using a Custom Rule.” You can use any namespace that you want. I would suggest using one namespace for custom claims and sticking with it. For this demo, I am using

This rule will add a claim to all users that log in from the Contoso STS that says “Company” = “Contoso”



All right so now we have the claim for people from Contoso, but we want to create exemptions for,, and

To do this, we need to go back to our Relying Party Authorization Rules and add a new custom rule.



Here’s how this rule breaks down. For a bit more details, I would highly suggest reading through the claims rule language primer.

Here’s the actual claim rule

c1:[Type == "", Value =~ "^(?i)Contoso$"]
&& c2:[Type == "", Value =~ "(?<!foo|bar|andy)"]
=> issue(Type = "", Value = "DenyUsersWithClaim");

Here’s the basic logic of the claim rule

If  ((claim.Company matches “Contoso”)  AND (claim.upn –NOTEQUAL ( OR OR Then (Issue “DenyUsersWithClaim”)

Perhaps the trickiest part here is the REGEX that filters out the exceptions. Basically, the “!” says “not match” and the “|” symbol is the Alternation operator – or functionally the "-or” operator.

Now, all users from Contoso will get denied access except for the 3 that match the regex.

Using Enterprise AD Credentials to Manage Azure Access Control Service

ACS is Azure’s Access Control Service. It is a cloud based Secure Token Service (STS). With the recent advent of Windows Azure Active Directory and ACS being offered for free, I am envisioning more and more enterprises beginning to leverage these services.

Typically, when you create a Azure ACS namespace, you login with a Windows Live ID and create/delete/manage services. However, if you have an Identity and Access Management team in your enterprise, you may want to have a bit more control over who can manage ACS and also ensure that they are using their AD credentials rather people’s personal Windows Live accounts. This is now completely possible using on premise ADFS.

This post assumes you have built out and installed an ADFS infrastructure and are familiar with adding Relying Parties and using claims.

To create a new ACS namespace, you will need to go to, log in to the portal, and then click on your name and choose Previous Portal.


In the old portal, you can manage Service Bus, Access Control, and caching.


Click on there and create a new ACS Namespace. Once the namespace is created, you can go in and manage “Identity Providers”

Typically, this is allowing you to add ID Providers that you will use to authenticate users to your Relying Parties. Live ID is there by default, and you can add more like Google, Facebook, and Yahoo!


The one you need here is WS-Federation ID Provider (ADFS 2.0)

From there you can give the URL of your ADFS federation metadata. It is typically something like

You must also add ACS as a Relying Party to your ADFS instance as well to establish a trust.

Now that you have added your ADFS service as a Trusted Identity Provider, you can use ADFS to authenticate your relying parties.

However, that is not the end goal in this scenario. We want to set up ACS so that we can log in to the management portal with our Active Directory Credentials. Here’s what else you need to do.

In ACS, to to Administration and choose Add Administrator


The one thing you will need to do is specify the claim and value that has permission to manage the portal.

I would suggest you use a Role claim and then in ADFS on your side, you can map a group in AD to that role claim.

Here’s the role claim


The value you specify is the value of the claim you set in ADFS when you add the claim rule to map a claim to a Group Membership. An example would be Domain\ACSAdministrators

To test this out, you should add yourself to the ACSAdministrators group you created and then try and authenticate to the management URL for your ACS Namespace. It will be something like From there, you will be prompted for which ID Provider you want to log in with. Choose your ADFS provider, log in with your corporate credentials, and you will have access to manage ACS.