Claims based Authentication – Part II
In previous post we started examination of the authentication process in our demo environment. Lets examine what happens in step 5 of the step-step guide. During this step Contoso STS was configured to work with Fabrikam STS. There were three primary steps in this process:
- Add Fabrikam STS as Identity Provider (IDP)
- Configure rules for incoming claims from Fabrikam IDP.
- Configure RP rules to process claims after they pass through the IDP rules.
Fabrikam IDP is configured with two rules:
| Rule # | Rule Type | Incoming Claim Type | Pass Through All Claim Values | Pass Through only a specific Claim Value | Pass through only claim values that end in a specific value | Pass through only claims that start with specific value |
| 1 | Pass Through Incoming Claim | E-Mail Address | @fabrikam.com | |||
| 2 | Pass Through Incoming Claim | Role | DrugTrial1Auditors |
So what does it mean? We are saying that Contoso STS will accept two types of claims from Fabrikam STS:
- E-Mail Address
- Role
Also, it will evaluate the value of incoming claim and will pass only claims with specific identified values. One thing we have to keep in mind here is that some time in the design process folks from Contoso and Fabrikam have actually discussed the type of claims will be exchanged between each STS. Because if Fabrikam STS is configured to send different types of claims to Contoso, nothing will work. Also, IDP rules are not sending incoming claims to actual RP or the user browser, they are received, evaluated and if they pass the filter, they are passed through onto the configured STS RP.
So next, RP rules must be modified to evaluate incoming claims and perform some action on them. Contoso SharePoint RP already has one rule set configured on it. Two new rules must be configured, one for each incoming claim type from Fabrikam IDP.
Contoso SharePoint RP is configured with two additional rules:
| Rule # | Rule Type | Incoming Claim Type | Outgoing Claim Type | Pass Through All Claim Values | Pass Through only a specific Claim Value | Pass through only claim values that end in a specific value | Pass through only claims that start with specific value |
| 1 | Pass Through Incoming Claim | Role | Yes | ||||
| 2 | Transform Incoming Claim | E-Mail Address | Name | Yes |
The first rule will pass through any “role” claim type, it doesn’t care about its value.
The second rule will take the value of the “E-Mail Address” claim and pass this value but in a different claim type – in this case as claim type of “Name”. This is powerful stuff. Contoso SharePoint needs to identify a user by its name and it does so via claim type of “Name”. Fabrikam on the other hand does not send this type of claim from its STS. If we could not do claim transformation then this solution would not work or both parties would have to agree on every single claim and its syntax, and every application would be required to comply with those requirements. Claim transformation eliminates this limitation and gives us a lot of flexibility.
Lets examine how one specific claim would go through Fabrikam IDP and then through Contoso SharePoint RP. In this example Fabrikam STS send the following Claim to Contoso STS:
| Incoming Claim Type | Claim Value |
| E-Mail Address | markw@fabrikam.com |
| Role | DrugTrial1Auditors |
Fabrikam IDP rules will examine this claim and since both conditions are met it will pass through it.
Next, the Contoso SharePoint RP will evaluate this claim. After it goes through its rules the resulting claim should have the following information:
| Outgoing Claim Type | Claim Value |
| Role | DrugTrial1Auditors |
| Name | markw@fabrikam.com |
This data will be send to the end user and then presented to the SharePoint site for authentication.
Key Learning's
|
In the next post we’ll examine how Fabrikam STS will construct outgoing claims and look at the whole flow of this process.