Claims based Authentication - Part I

Claims based authentication is getting more ground and with more practical applications we’ll see more and more adoption of this technology. Recently I downloaded and went through step-step demonstration on using Microsoft Office SharePoint Server 2007 and Active Directory Federation Services v2 (ADFS v2) beta 2 software. You can download this great demo at this location (https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=57602615-e1ee-4775-8b79-367b7007e178).

I have done simple implementations with ADFS v1 in the past and have read a good amount on ADFS v2 and in general on Claims based authentication, so I’m not new to this concept and technology in general. It doesn’t take long to go through all of the steps in this demonstration and it actually fairly easy and everything works. After going through all of the specified steps I scratched my head and thought, hmm, how is it exactly working, what is happening there, what kind of claims are going between IDP and RP, how are they configured and how can I modify this configuration to do other things? I like to visualize things, if it at all possible. This way I can see it, visually touch it and can get much better long term understanding on how this solution is actually working. So I decided to walk through this configuration and try to document some of those parts needed for better understanding of the entire message workflow.

If you are new to Claims based authentication, this post might not make much sense to you. There are a lot of resources on this subject. At the the of this post I provide some links to blogs and white papers that I think are very informational and educational.

First, I want to review the design of this demonstration. Figure 1 shows both Fabrikam and Contoso environments.

Figure 1. Base configuration of Fabrikam and Contoso

If you didn’t have a chance to review step-step document then here is a quick review of this solution. Contoso is doing business with Fabrikam and as part of their business environment they need to provide a secure collaboration portal. Contoso is using SharePoint 2007 to share documents between Contoso and Fabrikam. Contoso does not want to manage Fabrikams user accounts and Fabrikams does not want to have more than one user account and would like to have single sign on to access resources on Contoso SharePoint portal. Access to resources must be controlled via assigned roles. Some users should have only read access, some contributor access and some full access to the content.

As you can see, each company has its own Active Directory environment. They do not have Active Directory Forest or domain trusts and users in one environment can’t authenticate to other environment via AD trusts. Contoso AD does not have duplicate accounts for Fabrikam users.

Fabrikam users will access resources in Contoso SharePoint portal via Claims based authentication and they will have certain rights (roles) based on the assigned group membership in their own Fabrikam AD environment.

In step-step guide, in step 4 you’ll be asked to authenticate as Contoso\Administrator to the https://docs.contoso.com and add new roles to the site. In prior steps you configured this site to use “Role#Domain Admins” as site administrator and configured ContosoSRV01 ADFS with RP for SharePoint site with couple claim rules.

So what happens during this authentication and what type of claim is actually provided to the SharePoint site to give Contoso\Administrator administrative rights on the site? Figure 2 shows authentication steps.

Figure 2. Authentication by Contoso user

In step 1, Administrator accesses https://docs.contoso.com site, his browser reads the policy on the SharePoint site, discovers that it need to get a Claim from sts1.contoso.com and get redirected to it.

In step 2, he chooses to use Windows Integrated Authentication to authenticate to STS.

In step 3, he will get required claim from STS. STS is configured with the following rules:

Based on these rules, the content of this claim will be the following:

In step 4 this claim is send back to the https://docs.contoso.com SharePoint site.

Sharepoint site will take the claim, evaluate it and will find that one of the values in Claim Type Role is “Domain Admins” which matches its own configured Role type (“Role#Domain Admins”). Based on this match SharePoint will give our Administrator administrative rights to this site.

OK, this is fairly easy stuff. One to one matching and we are in business. As we can see Administrator Role Claim value has multiple groups in it. Obvious question begs the answer, can we configure SharePoint roles provider with any of these groups to give this user administrative access on the SharePoint? and the answer is yes. To prove this we can do a quick test. We’ll modify SharePoint to use “Role#Schema Admins” instead of “Role#Domain Admins”. Since Administrator account is member of Schema Admins group, he will have administrative rights on the site.

During step 4 (step-step guide) Administrator configures site with couple new roles: “Role#DrugTrial1Admins” and “Role#DrugTrial1Auditors”. At the end of step 4 we’ll authenticate as user Contoso\Danielw and verify that he has appropriate rights. Same flow will happen as shown in Figure 2. Based on the configured rules the claim will have the following values:

Because Daniels claim type ‘Role” has value matching SharePoint configured role, he is will be given appropriate rights on this site.

In the next post we’ll continue examination of this configuration.