Introduction

This is the third part of the series on Claim based Authentication and WIF. In the first part, we discussed the basics of Claim based Authentication and in the second part, we explored the WIF and also discussed an example and made a Custom Identity Provider (IP) and ASP.NET application(RP). This ASP.NET application uses the Identity provider for authentication.

You can find these two articles below:

Now in this post, we will discuss the problems of the model that we discussed in our earlier articles.

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 where one might require to use several Identity Providers like Facebook, Google, Windows Live id, etc. It'll look something this:

Let's say, I made an application and I want to allow users to give options to choose the Identity Providers. Then the flow diagram would be like:

But as in the open world, Identity Providers use different protocols and some have 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 code 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. It would mean you need to change the code for your application to accommodate the new identity provider. So this is not a good approach because you need to change the RP code every time.

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

One more scenario, if a user uses an Identity provider that is not trusted by the application. But if there is an one Identity provider trusted by some another identity provider, that in turn trusted by the application, this is called Identity federation.

All these above scenarios 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 issues a generic token that actually can be understood by the application, i.e., the application only trusts the federated provider. All the plumbing code to understand various Identity Providers has been moved to federated provider.

This makes 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 accesses 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 a list of Identity Providers to the user to get authenticated.

Step 4: Now the user gets a list trusted Identity Provider and it selects an Identity provider (where it has an account) and authenticates itself. 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 first verifies the token and decrypts it if required. It verifies and reads the incoming token and issues 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 access to the application.

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

So from the above flow, we understand that not only one relying party trusts the Identity provider, but an Identity Provider can trust another Identity provider as well.

Also in the above scenario, two Identity providers come into the picture. The 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 the requirement. These types of things can take place in federated provider Windows Azure Access Control Service that work on the same model. In that, ACS plays the role of the Federated Provider and there we specify some pre-specified Identity Providers like Facebook, Google, adfs, etc. We'll discuss it in detail in my next post.

History

26^th November, 2011: Initial post

Claim based Authentication- WIF: Part 3