Claim Based Authentication IV
In previous three posts we examined how claim authentication flow works for users in the same domain as SharePoint site and for users from other organizations. As we have seen, the value for Role claim was based on the Active Directory group membership. For instance, Frank Miller from Fabrikam was given role of DrugTrial1Auditors in Contoso SharePoint site because he was member of DrugTrial1Auditors AD group in Fabrikom.com domain. With current configuration Contoso has no say which users from Fabrikam have DrugTrial1Auditors role on Contoso SharePoint site. Contoso trusts Fabrikam administrators to ensure that only authorized employees for DrugfTrial1Auditors belong to the Fabrikam DrugTrial1Auditors group. This can be perfect in some situations, but sometimes it might be not the best solution. What if Contoso wants to control what type of access users from Fabrikam should have to the Contoso SharePoint site, but at the same time they do not want to manage or create accounts for Fabrikam users? There is a great solution for it and step 8 in the demonstration shows a sample on how we can use SQL server database as source for external attributes for claim values. Figure 1 shows example tables for this solution.
Figure 1. External data source for user information
Table dbo.TS contains information about which SharePoint site belongs to which drug trial.
Table dbo.URT contains a list of e-mail addresses of users, the role that they have, and the drug trial that they belong to.
Table dbo.RS maps the roles in the database to the roles in the Contoso SharePoint site.
To accommodate data in these tables we had to modify SharePoint site. It was reconfigured with new roles: Role#sp_admin and Role#sp_visitor. DrugTrial1Auditor role and DrugTrial1Admin role were removed from the portal. Also, new datasource was added: “HOL Doctors Role” database.
Three new rules were created on the Contoso SharePoint RP. Each rule is using one of the database tables. Check out this site for ADFS v2 rule language format:
https://technet.microsoft.com/en-us/library/dd807118(WS.10).aspx
The first rule check which trial the https://docs.contoso.com/ site belongs to:
=> add(store = "HOL Doctors Role", types = (" https://schemas.microsoft.com/ws/2008/06/identity/claims/trial") , query = "select trial from dbo.TS where dbo.TS.SharePointSite = {0}", param = " https://docs.contoso.com/");
In second rule, we use the previously queried trial information with the user’s e-mail address and discover which role the user belongs to:
c1:[Type == "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
&& c2:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/trial"]
=> add(store = "HOL Doctors Role", types = ("https://schemas.microsoft.com/ws/2008/06/identity/claims/incomingtrialrole"), query = "select role from dbo.URT where dbo.URT.Trial = {1} and dbo.URT.UserName={0}", param = c1.Value, param = c2.Value);
In the third rule, we use a previously queried role claim to query the SharePoint role claim and assign the value to the outgoing role claim:
c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/incomingtrialrole"]
=> issue(store = "HOL Doctors Role", types = ("https://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = "select dbo.RS.SharePointGroup from dbo.RS where dbo.RS.Role = {0}", param = c.Value);
Lets take a look at how claim flow will work in this new configuration. Figure 2 shows slightly modified flow of authentication to Contoso SharePoint site from Fabrikam user.
Figure 2. Authentication by Fabrikam user to Contoso SharePoint site
Fabrikam user Frank Miller will access Contoso SharePoint site.
In step 1, Frank opens his browser and opens https://docs.contoso.com site. SharePoint site will provide its policy information a redirect Franks browser to a trusted STS.
In step 2, Franks browser will access https://sts1.contoso.com and reads its policy. At this point Frank must select his home realm. If Information Card was already configured in Fabrikam forest for Contoso SharePoint site, the home realm discovery would automatically redirect his browser to his home STS. Without Information Card, he would be required to choose his STS server in the drop down list. At this point no claims yet have been exchanged and all authentication been done via anonymous authentication mechanism.
In step 3, Franks computer will authenticate to the STS. Since our STS is running on the same computer as Domain Controller, it is already authenticated to it, so it just presents existing Kerberos ticket, which will have all required information in it, such as list of groups this user belongs to (list of SIDs of those groups).
In step 4, Fabrikam STS will create and process new claim for Frank Miller. The first rule will create the following claim:
| Outgoing Claim Type | Claim Value |
| E-Mail Address | frankm@fabrikam.com |
| Role | DrugTrial1Auditors Purchaser Domain Users |
Next, it will pass this claim onto second and 3rd rules. Second rule allows to pass all claims with any E-Mail Address. 3rd rule will check value of the Role claim type and it will discard 2 values out of this claim. The final outgoing claim from Fabrikam STS for user Frank Miller should have the following information:
| Outgoing Claim Type | Claim Value |
| E-Mail Address | frankm@fabrikam.com |
| Role | DrugTrial1Auditors |
In step 5 this claim is delivered back to Franks computer.
So now Frank has his claim from Fabrikam STS. Can he present this claim to Contoso SharePoint site? It would not work because Contoso SharePoint site does not trust Fabrikam STS, it only trusts Contoso STS and it would accept claims only from Contoso STS.
In step 6, Franks computer will deliver his claim to Contoso STS.
Now it is up to Contoso STS to evaluate incoming claim and decide what to do with it. In steps 7, 8 and 9 Contoso STS receives incoming claim from Fabrikam STS and it will pass it onto Fabrikam IDP rule set configured on Contoso STS. If you remember, those rules will evaluate incoming claim values and will pass claims only if their E-Mail Address value ends with @fabrikam.com and its role value is equal to DrugTrial1Users. Incoming claim from Frank satisfies both criteria. At this point Contoso STS accepted incoming claim, it is not going back out yet to the user computer. The value of this claim should be the same as it came in:
| Outgoing Claim Type | Claim Value |
| E-Mail Address | frankm@fabrikam.com |
| Role | DrugTrial1Auditors |
Next, it will pass this claim onto Relying party rule set to create outgoing claim suitable for the SharePoint. Now Contoso SharePoint RP is configured with five rules for incoming claims. First one will pass Role claim type without any changes to its Role type. Second rule is a transformation rule. It will change the E-mail Address claim type to Name claim type, but will keep its value the same. The 3rd rule will identify that DrugTrial1 trial belongs to https://docs.contoso.com site. The forth rule will identify that Frank has Admin role in DrugTrial1 trial. And finally, the fifth rule will identify that Admin for DrugTrial1 mapped to sp_admin role in SharePoint site.
The final claim for Frank Miller, coming out from Contoso STS destined for SharePoint RP should look like this:
| Outgoing Claim Type | Claim Value |
| Name | frankm@fabrikam.com |
| Role | sp_admin |
OK, to recoup, lets compare claim originated at Fabriakm STS and final claim delivered to Contoso SharePoint:
.