Home / My Disclaimer / Who am I? / Search... / Sign in

Creating a Claims Provider Trust in ADFS 2

by Steve Syfuhs / April 25, 2011 04:00 PM

One of the cornerstones of ADFS is the concept of federation (one would hope anyway, given the name), which is defined as a user's authentication process across applications, organizations, or companies.  Or simply put, my company Contoso is a partner with Fabrikam.  Fabrikam employees need access to one of my applications, so we create a federated trust between my application and their user store, so they can log into my application using their internal Active Directory.  In this case, via ADFS.

So lets break this down into manageable bits. 

First we have our application.  This application is a relying party to my ADFS instance.  By now hopefully this is relatively routine.

Next we have the trust between our ADFS and our partner company's STS.  If the company had ADFS installed, we could just create a trust between the two, but lets go one step further and give anyone with a Live ID access to this application.  Therefore we need to create a trust between the Live ID STS and our ADFS server.

This is easier than most people may think.  We can just use Windows Azure Access Control Services (v2).  ACS can be set up very easily to federate with Live ID (or Google, Yahoo, Facebook, etc), so we just need to federate with ACS, and ACS needs to federate with Live ID.

Creating a trust between ADFS and ACS requires two parts.  First we need to tell ADFS about ACS, and second we need to tell ACS about ADFS.

To explain a bit further, we need to make ACS a Claims Provider to ADFS, so ADFS can call on ACS for authentication.  Then we need to make ADFS a relying party to ACS, so ADFS can consume the token from ACS.  Or rather, so ACS doesn't freak out when it see's a request for a token for ADFS.

This may seem a bit confusing at first, but it will become clearer when we walk through the process.

First we need to get the Federation Metadata for our ACS instance.  In this case I've created an ACS namespace called "syfuhs2".  The metadata can be found here: https://syfuhs2.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml.

Next I need to create a relying party in ACS, telling it about ADFS.  To do that browse to the Relying party applications section within the ACS management portal and create a new relying party:


Because ADFS natively supports trusts, I can just pass in the metadata for ADFS to ACS, and it will pull out the requisite pieces:


Once that is saved you can create a rule for the transform under the Rule Groups section:


For this I'm just going to generate a default set of rules.


This should take care of the ACS side of things.  Next we move into ADFS.

Within ADFS we want to browse to the Claims Provider Trusts section:


And then we right-click > Add Claims Provider Trust

This should open a Wizard:


Follow through the wizard and fill in the metadata field:


Having Token Services that properly generate metadata is a godsend.  Just sayin'.

Once the wizard has finished, it will open a Claims Transform wizard for incoming claims.  This is just a set of claims rules that get applied to any tokens received by ADFS.  In other words, what should happen to the claims within the token we receive from ACS?

In this case I'm just going to pass any claims through:


In practice, you should write a rule that filters out any extraneous claims that you don't necessarily trust.  For instance, if I were to receive a role claim with a value "Administrator" I may not want to let it through because that could give administrative access to the user, even though it wasn't explicitly set by someone managing the application.

Once all is said and done, you can browse to the RP, redirect for authentication and will be presenting with this screen:


After you've made your first selection, a cookie will be generated and you won't be redirected to this screen again.  If you select ACS, you then get redirected to the ACS Home Realm selection page (or directly to Live ID if you only have Live ID).

Comments (3) -

Milos Cekovic
Milos Cekovic Switzerland
2/16/2012 7:56:54 AM #

Hi Steve,
I have configured ACS as IdP (Claims Provider Trust) on my on premises ADFS. I have my simple claims aware WS-Fed application.
If I access the application the flow is as following:
1) ADFS HRD -> I choose ACS
2) ACS HRD -> I choose, e.g. Google and log in
3) I land on the claims aware application which dumps all the claims Google is providing over ACS (name, nameidentifier, emailaddress and identityprovider)

So far so good. The problem is that the Acceptance Transform Rules that I have defined in the ACS Claims Provider Trust does not fire at all. I can put whatever I want inthere, only the Google claims are provided to the app. I can remove all the rules from the ACS Claims Provider Trust, same behavior (only Google claims).

My requirement is to "enrich" the Google claims with some claims from my attribute store. This does not work.

Any idea? Is "double-HRD" supported scenario?


steve United States
2/20/2012 12:32:17 PM #

Seems like it would be a supported scenario. All it's doing is transforming incoming claims. Let me look into it.

Milos Cekovic
Milos Cekovic Switzerland
3/6/2012 12:13:55 AM #

Hi Steve,
Did you have a chance to take a look into this? I have not found any explanation, why Acceptance Transform Rules for ACS Claims Provider Trust in ADFS do not fire at all.

My analysis showed that the ACS is creating a RequestSecurityTokenResponse with all the claims Google is providing and redirecting back to my ADFS (to /adfs/ls/). The issuer in this RequestSecurityTokenResponse is set to my ACS instance (something like myfederation-sb.accesscontrol.appfabriclabs.com) and not Google, which is OK. IMHO this first  RequestSecurityTokenResponse looks OK.

But then, ADFS does not use the claim rules defined for my ACS Claims Provider Trust to process the token. It applies only Issuance Transform Rules of the relying party (i.e. of my claims aware aplication, that is defined as RP in ADFS).

I assume that this is because of the doucle HRD process. I have the same claims aware app in the single HRD process, and everything works fine.

Comments are closed

// About

Steve is a renaissance kid when it comes to technology. He spends his time in the security stack.