Click here to Skip to main content
15,867,330 members
Articles / Hosted Services / Azure

Claim based Authentication- WIF: Part 3

Rate me:
Please Sign up or sign in to vote.
5.00/5 (13 votes)
26 Nov 2011CPOL5 min read 55K   30   11
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:

Image 1

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:

Image 2

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:

Image 3

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)


Written By
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: Code Wala

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

Comments and Discussions

 
QuestionClaim Based Authentication and Authorization from Active Directory using Windows Identity Foundation Pin
moazjutt20-Oct-15 1:56
moazjutt20-Oct-15 1:56 
Hello Brij,

It is such a nice Article. Lot of things, I learnt from it. Actually I am working on a security module which require Authentication and claim based Authorization from Active Directory using Windows Identity Foundation. I followed your tutorial and finally i am stuck at a point where we have to set the path for FederationMetadata.xml. An error message is displayed

"ID1014: Could not parse the WS-Federation metadata document. Root Element is missing."

when i press on Next button. Please advise Also i actually want to do the same thing using Active Directory.

NOTE: User Authentication from AD using DirectoryDervices is not my Requirement.

It would be really appreciated if you Guide me in this regard.

Thanks In Advance
GeneralMy vote of 5 Pin
Member 103429602-Mar-15 8:40
Member 103429602-Mar-15 8:40 
GeneralMy vote of 5 Pin
eferreyra24-Jul-14 2:10
eferreyra24-Jul-14 2:10 
SuggestionGreat Article -- But would be better if u have one more part Pin
Jegatheeswaran M24-Oct-12 4:25
professionalJegatheeswaran M24-Oct-12 4:25 
GeneralRe: Great Article -- But would be better if u have one more part Pin
Brij30-Oct-12 23:50
mentorBrij30-Oct-12 23:50 
QuestionHow comw Facebook is Identity Provider? Pin
Sharath Kumar G R22-Aug-12 2:58
Sharath Kumar G R22-Aug-12 2:58 
AnswerRe: How comw Facebook is Identity Provider? Pin
Brij23-Aug-12 5:16
mentorBrij23-Aug-12 5:16 
GeneralRe: How comw Facebook is Identity Provider? Pin
Sharath Kumar G R11-Sep-12 0:24
Sharath Kumar G R11-Sep-12 0:24 
GeneralYou are the man Pin
jonymargo11-Dec-11 13:49
jonymargo11-Dec-11 13:49 
GeneralRe: You are the man Pin
Brij12-Dec-11 4:56
mentorBrij12-Dec-11 4:56 
GeneralMy vote of 5 Pin
jonymargo11-Dec-11 13:47
jonymargo11-Dec-11 13:47 

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

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