I created a list of topics last night that I think will be useful to put up here…Going in any kind of order will be too tough for me (lazy) and I’m afraid it would slow down my blog production. Please let me know if you would like to see something specific. Otherwise, I’ll just try to keep putting stuff up in random order.
If you aren’t familiar with Claims in ADFS – I’d suggest this short read on TechNet before going any further. As you will find with most of my blogs – it will be helpful to get Nick’s step-by-step up and running so you can follow along.
In this doc, I’ll go through the steps to create an Organizational Group Claim and map it from the Account Partner to the Resource Partner and then send it to an application.
While this information may not be useful/interesting for everyone, I find myself going through it with several people I talk to about ADFS. Most people have it down about 90% of the way – but aren’t super crisp on all the steps and why you take them. I’ll follow this up with a more in-depth blog which discusses all three claim types with some real world examples of how things should be setup. Custom claims and how you use them is just one item that could certainly use some further explanation. I didn’t understand claims 100% myself for a very long time (maybe I still don’t – but I think I can fake it now).
There isn’t a right or wrong way with the order in which you do this (other than the Organizational Claim must be created first on both sides), so I’ll just tell you my way.
The steps I take are as follows:
Start on the Account Partner
1. Create Organizational Group Claim on the Account Side
2. Right click the account store and do a new Group Claim Extraction
3. Right click the resource partner and do a new Outgoing Group Claim Mapping
Next – go to the Resource Partner
1. Create an Organizational Group Claim and associate it with a Windows Security Group on the resource group tab
2. Right click the account partner and choose New Incoming Group Claim Mapping
3. Highlight the application in which you want to receive this claim and choose enable
There are a couple things to help you remember this –
1. You need to visit/configure the claim in three places on each side
2. The above order is very similar to how the claim flows when a user access an app
A very common error I see is associating the claim with a Windows Group on the account side by using the resource group tab (like you do on the resource side). This is not correct – it won’t prevent it from working, but it is an unnecessary step. On the account side – the claim is associated to the Windows group via the group claim extraction (step 2) method. Since it’s the account side (no application) – we don’t need to associate the Group Claim to a Windows Group – we only need to extract the claim from the account store (another way to say this – we need to figure out which users get this claim)
Let’s go through everything from start to finish and hopefully it will become clear.
Notice the Resource Group tab doesn’t have anything configured
2. Do a new group claim extraction from your account store. This is where you are saying – if you are a member of this Windows Group – I want you to have this Group Claim
3. Map the group claim by doing a new outgoing group claim mapping on the resource partner. The outgoing group claim name must match EXACTLY when we complete the steps on the resource partner. Personally, I use all lower case and hyphens to help minimize errors here. Also, think about what you name the mapping – you wouldn’t want to call this “example-outgoing-mapping” because that wouldn’t make sense when you type that name in on the resource side. On the resource side – it will be an incoming group claim mapping. This is just a tip to help keep things manageable – any name will work so long as they match on both sides.
That’s it for the account side – now we go to the resource federation server to configure the rest of the claim mapping.
1. Create an Organizational Group Claim – it is important to note that this claim name doesn’t have to match the Group Claim name which we configured for the Account side. In fact – the name will be different in most cases. The name here should be something logical for the resource side administrator – imagine 200 or 300 group claims – you want the display name to mean something to you.
Now – go to the resource group tab and associate a Windows Group to this claim. This is where you say – if a user comes to my application with this group claim – I want to associate it with this Windows Group. Typically, this group is empty. The Windows Group SID will be written to the web server (for token based apps) and the application will think that it’s a regular user with this group membership accessing it.
2. Remember, you must have at least one Identity claim – then you can have one or more group or custom claims here. The one identity claim is the only rule that can’t be broken. Notice how all my claims show up when I highlight Blog Application – but only UPN identity claim and Resource Example Group claim are highlighted (enabled)
3. Create the incoming group claim mapping from the account partner. Remember – we need to have an exact match on the claim mapping name.
That’s it! We’ve completed setting up a group claim mapping for a federated WebSSO scenario.