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.
very cool jim
ill be sure to keep an eye on this - already linked to it.
Hi Jim, thanks for posting this info out there. We are still looking for a guide to setting up Web SSO with an FSP. We've got it set up and working but can't validate the architecture without a step-by-step guide for Web SSO. Main questions surrounding this are: Is ADAM required in any Web SSO scenrio? If not, where do the accounts reside? Also, how can Web SSO do claims mappings when technically there are no claims because your user is external and not domain-joined? TIA!
Someone suggested that I do some blog content around FS-P today and I'll put the WebSSO scenario on the list as well...
In the meantime - I'll try to answer your questions. ADAM is not required - you can use Active Directory or ADAM as your account store in a WebSSO scenario.
When you are in this scenario, it means all the information is contained/configured under the My Organization node of adfs.msc. With that said, there is not a need to map Account-Org-Claim A to Resource-Org-Claim A as described above.
In WebSSO - you have an account store (ADAM or AD) where your users reside, you have Organizational Claims that can be linked to Windows groups, and you extract the group claim from your account store. Also - you will have an application which has the desired claims enabled. Again, all of this is under the My Organization node and the partner node is empty.
As far as the FS-P goes, nothing changes here. If you configure a FS-P for a WebSSO scenario - it is the exact steps as configuring a FS-P for Federated WebSSO.
Nick did a nice job on documenting the Proxy setup - located here:
Remember - the Proxy can be placed in front of a FS-A or a FS-R or (in this case) a FS-A/R - nothing changes with the config.
First I would like to thank you for your blog.
My lab environment is working but:
I created a test1 user and it is member of the "treyclaimappusers" group. test1 is able to access the application web page.
I created a test2 user and it is NOT member of the "treyclaimappusers" group BUT still test2 is able to access the web page. So, regardless of the user on the account side if it is member or not of that group they are able to access the web page.
May you please tell me what am I doing wrong?
Thank you for your time.
I am new to this blog.
I encounter exactly the same problem as described in the post by "enymay 09-22-2008 11:43 PM "
I still have not found a clue either so far.
Does anybody have an explanation for this ?
enymay 09-22-2008 11:43 PM
...... My lab environment is working but:
May you please tell me what am I doing wrong? ......