Click here to Skip to main content
Click here to Skip to main content

Claim based Authentication- WIF: Part 3

, 26 Nov 2011
Rate this:
Please Sign up or sign in to vote.
This article discusses some problems with the earlier approach and discusses Identity federation

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.

fourth.png

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

  • 26th November, 2011: Initial post

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Brij
Software Developer (Senior)
India India
Brij is a 3-times Microsoft MVP in ASP.NET/IIS Category and a passionate .NET developer. More than 6 years of experience in IT field, currently serving a MNC as a Tech Lead/Architect.
 
He is a very passionate .NET developer and have expertise over Web technologies like ASP.NET 2.0/3.5/4.0, jQuery, JSON, Javascript, IIS and related technologies. He is also a Exchange Server (EWS) Specialist. He has great experience in design patterns and N-Tier Architecture.
 
He is also certified as Microsoft Certified Technologies Specialist-ASP.NET and Microsoft Certified Technologies Specialist-WCF in .NET 4.0. He has also received several awards at various forums and his various articles got listed as "Article of the day" at ASP.NET Microsoft Official Website www.asp.net.
 
He has done MCA from NIT Durgapur and completed his graduation from Lucknow University.
 
Learning new technologies and sharing knowledge excites him most. Blogging, solving problems at various forums, helping people, keeps him busy entire day.


Visit his Blog: Brij's arena of .NET
 
Area of Expertise :
C#, ASP.NET 2.0,3.5,4.0, AJAX, JQuery, JSON, XML, XSLT, ADO.Net, WCF, Active Directory, Exchange Server 2007 (EWS), Java script, Web Services ,Win services, DotnetNuke, WSS 3.0,Sharepoint Designer, SQL Server 2000/2005/2008
Follow on   Twitter

Comments and Discussions

 
GeneralMy vote of 5 Pinmembereferreyra24-Jul-14 2:10 
SuggestionGreat Article -- But would be better if u have one more part PinmemberJegatheeswaran M24-Oct-12 4:25 
GeneralRe: Great Article -- But would be better if u have one more part PinmentorBrij30-Oct-12 23:50 
QuestionHow comw Facebook is Identity Provider? PinmemberSharath Kumar G R22-Aug-12 2:58 
AnswerRe: How comw Facebook is Identity Provider? PinmentorBrij23-Aug-12 5:16 
GeneralRe: How comw Facebook is Identity Provider? PinmemberSharath Kumar G R11-Sep-12 0:24 
GeneralYou are the man Pinmemberjonymargo11-Dec-11 13:49 
You are the man, Can you tell us when is the next post on this series.
GeneralRe: You are the man PinmvpBrij12-Dec-11 4:56 
GeneralMy vote of 5 Pinmemberjonymargo11-Dec-11 13:47 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web04 | 2.8.140814.1 | Last Updated 26 Nov 2011
Article Copyright 2011 by Brij
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid