Getting ADFS claims from AD when user logs in via Azure ACS

Question

Our chain goes:

ASP.NET app with WIF -> ADFS -> and maybe Azure ACS -> Facebook, Google etc.

We have users configured in AD with roles etc. These users can log-on to AD via ADFS and get their roles as per normal.

Optionally, they can log-on to one of the ACS providers and we have a use case that stores the ACS provider's unique ID in AD. If they use more than one provider, we have more than one mapping.

So we can map the user who log ins in via ACS to their "real" identity in AD.

What we are battling with is how to deliver the full set of claims to the users who login via ACS? Typically, you just get a name, email address and unique id.

Is there a claim rule that can search AD using the unique ID? This rule would have to establish which provider they used in order to use the correct unique ID in AD.

I guess we could query AD from the application but that means we have to add the code to all such applications?

We could probably do the conversion in a custom STS as well?

Any ideas, good links, articles etc?

Answer 1

Your scenario might have less friction if your chain looked like this instead:

ASP.NET app with WIF -> Azure ACS -> (ADFS or Google or Facebook)

Is this a viable option?

ACS integrates best with ADFS when ADFS is acting as an identity provider rather than a relying party. Furthermore, in one hand ADFS will happily federate with external identity providers to grant access to users from foreign directories, but I don't think you can get ADFS to authenticate users from its own local AD directory using a token issued from ACS.

Answer 2

You can achieve this by creating a custom rule in ADFS using the Claim Rule Language in the Claims Provider Trust for ACS (see here and here for some language documentation).

But: I'm not sure if you can search the AD with the unique ID right away, as the param type used to query the AD isn't specified in the Claim Rule Language. The rule templates use the windows account name (layout: DOMAIN\USERNAME) to search, thus I'd recommend using a (custom) attribute store instead of AD itself and map the unique ID to a windows account name.

Assuming you have your attribute store set up, you can create custom rules that set the windows account name claim and enables you to query AD with the template rules of ADFS.

The custom rule would look something like this:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]
 => add(store = "YourAttributeStore", 
  types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"),
  query = "{0}", param = c.Value);

To really enable the template rules you also need to set the issuer on the newly generated claim, because they check if it comes from "AD AUTHORITY". I don't know if this is a legit approach but I do this for convenience. This requires a second rule that will look something like this:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(Issuer = "AD AUTHORITY", OriginalIssuer = "AD AUTHORITY",
  Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
  Value = c.Value);

Regarding the distinction of different unique ID providers, it's your choice on how to handle it. You could create a custom rule for every provider, let the attribute store make the distinction or make generic queries to your attribute store. The documentation of the Claim Rule Language should help you here.

---

Note: This seems to be a topic commonly avoided in books about ADFS/WIF/Claims based Identity. This is my personal solution and it may not be best practice, it's just the most convenient I came up with. If anyone knows coverage of this particular topic: please share.

Also note: rule order matters in ADFS, the claim(s) created in the first rule are available in the following rules and so on, this is what makes this possible.

Edit: didn't see this Question was asked one year ago ... hope this answer is helpful to someone anyway.