Claim based Authentication Tutorial Part 3

In our last example we discussed the simple approach to use Custom Identity Provider for Authentication. But things are not as simple as we discussed. Now as we externalize the Authentication system and use Identity Provider to authenticate a user. There are situations one might require to use several Identity Providers like facebook, google, windows live id etc. It’ll look like something this

Let’s say, I made an application and I want users are allowed to give options to choose the Identity Providers. It can be implemented making a trust relationship between the RP and multiple Identity providers. Then the flow diagram would be like

But as in open world, Identity Providers using different protocols and some has developed their own proprietary protocol, so your RP must understand all these protocols. So your application understands all these protocols and can verify and read the token. For this, we need to write the extra codes to handle all these various protocols. Now the scenario would be like this

This is not a good solution. And what if you want to add one more Identity Provider to your Relying Party. Means you need to change the code for your application to accommodate the new identity provider. So this is not good approach because every time, you need to change the RP code every time.

Now lets take another scenario, In your organization there are several applications available to users and these application trusts several Identity Providers. Now you need to write the plumbing code in every application to handle all these Identity providers.

One more scenario, If user uses an Identity provider that does not trusted by the application. But if there is an one Identity provider trust some another identity provider that in turns trusted by the application. This is Called Identity federation.

All these above scenario can be easily handled by Identity federation. i e you can have an Identity provider (known as federated Provider), that actually receives (trusts) first the tokens from all the various Identity Providers and then issue a generic token that actually can be understood by the Application. i e the application only trusts the federated provider.Allthe plumbing code to understand various Identity Providers has been moved to federated provider.

This makes the life very easy

Now you can see all the above problems can be easily handled. So Now let’s discuss how the process flows.

Step 1: User access the Relying Party Application.

Step 2: As user is not authenticated, Relying Party application forwards the user to its trusted Identity provider ( here Federated Provider to get Authenticated)

Step 3: Now the federated provider, itself is not an Identity Provider, It relies on several other Identity Providers. So it gives list of Identity Providers to the user to get Authenticated.

Step 4:Now user gets a list trusted Identity Provider and it selects an Identity provider (where it has an account) and authenticate it self. Once authenticated a Token is issued for the User by the selected Identity provider and passed to the Federated Provider.

Step 5:Now as Federation provider trusts the Identity provider, it can understand the token. It firs verifies the token and decrypt it if required. It verifies and read the incoming token And issue a New token and transforms the Claims from Identity provider token using Claim rules (if any) to new token.

Step 6: The new Token (issued by FP) is passed to Application (Relying Party).

Step 7:And this token is forwarded to Relying Party. As relying party trusts the federated provider It can understand the token and verifies it and once verification gets successful. It allows the access to application.

So the above process takes place behind the scene and user does not need to care about it. user just need to select one of the listed Identity providers, select and put the credentials to authenticate. All rest process takes place behind thescene.The whole process also termed as Single Sign On.

So form the above flow, we understand that , Not only one relying party trust the Identity provider and an Identity Provider can trust another Identity provider as well.

Also in the above scenario, Two Identity providers come into the Picture. First provider sends the token to other provider with Claims. Now the second provider has an option to transform like removing a Claim, and a new Claim, changing the two or more claims into one, splitting one claim into two or more etc.. This can be done based on te requirement. These type the things can take place in federated provider Windows Azure Access Control Service works on the same model. In that ACS plays the role the Federated Provider and there we specify some pre-specified Identity Providers like facebook, google, adfs etc.