Click here to Skip to main content
13,147,812 members (35,962 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


6 bookmarked
Posted 10 Jun 2013

Claim based Authentication: Part 4

, 10 Jun 2013
Rate this:
Please Sign up or sign in to vote.
Claim based authentication.

Its a little gap in between my third and fourth part, anyways I am going to write 4th part of the series. First you can read my earlier parts from the link below.

As if you have read my earlier posts in the series, you can visualize  that in my first post I discussed about the Idea about Claim based authentication, basics and various components of Claim based authentication.

In part 2, we discussed about Windows Identity Foundation (WIF) and also created a step by step simple example using WIF.

In part 3, we discussed the problem of the approach discussed in part 2 and discussed that these problems can be avoided if we use a Federated Provider. In this post we’ll implement the federated provider in a simple solution.

To continue reading this post, it’ll be better to go through at least part 3 post in the series.

Just to brief, In federated scenario, two Identity Providers comes into the picture : one is Identity Provider (where user puts its credentials) and another is Federated Provider which understands all the Identity Providers and accordingly creates a new token that is understood by the relying party. Relying party does not care about Identity Providers, rather it just trust the Federated Provider and can understand the token issued by it. It can be pictorially depicted as


As here in above image, we can see that every Identity Provider send different type of token. Access control service process these and create a new token and sends to Relying Party.

We can have our own custom Identity Provider and Federated provider as well.  In Microsoft stack, Access Control Service is one of the most popular service which serves the purpose of a federated provider. It is Pay-As-You-Go service on Azure and provides all the basic infrastructure and requires less or no amount of coding. Access Control Service is now called Windows Azure Active Directory.

In today’s post, I’ll create a step by step example to implement the Federated provider using Windows Azure Active Directory. First let me discuss the various components while using federated provider . So there would be at least  four components

  1. Client
  2. Identity Provider(s)
  3. Federated Provider
  4. Relying Party

As we have already discussed all the above components in my last post. we ‘ll create a step by step example of Federated Provider. Here Identity provider could be any third party Identity Provider or our own Identity Provider. Windows Azure Active Directory works as Federated Provider and a application hosted on my local machine will be relying party.

Let’s go step by step. First we need to create a namespace at azure Access control. For this first one need to be registered on If you have account here then you can continue else you’ll require to register here before proceed.

Here we’ll login azure portal ( and create a Active Directory Access Control namespace for our Federated Provider that will be used by our application (Relying Party). After login it redirects to home page and provides many options in left pane of the Home page as


Here to quickly create the Active Directory Access Control namespace click on the encircled new button in left bottom as in above screen shot. It opens up a window.

Select App Service ->Access Control -> Quick Create. It asks for namespace and region. The namespace should be globally unique, else it will not be accepted. After filling it click on Create


I have given here namespace CBAPart4 and selected region Southeast Asia. Here you can see encircled green tick mark which means the namespace available. After creating, it will be enlisted in your account with status active few minutes as:


On this page, click on Manage button at bottom middle of the page which takes us at different page in a new tab/window with left pane as


Now click on Identity Providers which allows to add Identity providers for this Federated Provider. It takes us at below screen


It has added by default added Windows Live Id as an Identity Provider. We can add other providers by click on Add link encircled in the above screen shot.


Here we have some already pre-configured Identity Providers like Google, Yahoo and custom Identity Providers like facebook, ADFS 2.0 (Active Directory Federation Services).  Let’s add Google here


It asks the that display and any image for that if we want to show that at login link. I provided an image and Clicked on save. Similarly we can add Yahoo as an Identity provider. Now we have three Identity providers for our federation provider: Google, Yahoo and Windows Live Id.

Next we require to add the Relying Party. Means our application that will be authenticated via this Federated Provider. To add the Relying Party applications, click on Relying Party applications link, it takes us


Here I provided the name to my Application as MyRelyingPartyApp . There are two ways to add settings. Select the first one (Enter settings manually) as encircled in mode section. We need to provide two URLs. Here one is for which the token is issued (also called Realm) and another where the federation provider returns the access token. Leave the rest of the settings of section Relying Party Application Settings section and move to next section Authentication settings on the same page as


Here it lists all the Identity Providers that we added , we need to select all which we want to use. I selected all. Now we need to create the rules. So first require to create a Rule Group then rules under that rule group.  We either can use any existing rule group (if exists which can serve the purpose) or can create a new one. I’ll be telling why do we require the rules in coming section.

Token is required to be signed to check the integrity at the target application. Here I have selected the default option for this demo. We can provide our own certificate that can be used for token signing.

Rule – Rules are very important here. Identity Providers sends token with claims to Federated Provider. As Federated provider trust Identity Provider so it knows the format and details about token and can read it. Federated provider first checks the integrity of token then read the required data and creates a new token with claims. Then Federated provider sends this token to Relying party. Here this rule is to convert the claim provided by Federated Provider to some other claim type that can be understood by Relying party.  We can easily pass through the same just creating a rule with pass through.

Rules also are very helpful because we not want to sends all the claims to Relying party or want to combine some claims. These scenarios is handled by these rules.

To add the rules, click on the Rule Groups from left pane


It adds  by default a rule group for added Relying party. We can create new one . We need to add the rules in the rule group assigned to Relying party. For that click on Default rule group on the above screen shot and it redirects us to


Here we can see the details of the rule group. It is for the Relying party that we added as second encircled . Now in this group there is no rule. Either we can add some rules or we can simply check on Generate button, which redirects us a page which list down all the Identity Providers for this Federated Provider namespace and again click on generate button which just add the default claim rules that just pass the claims returned by Federated Provider as is. A rule is created is for each claim which has input claim and output claim as


Else we can create rule by our self by clicking on the Add link as encircled in the previous screenshot as:


It has three section, first section If  first option Identity provider, once we select it accordingly it populates all the claims provided. As I selected Google and enlist all the claims by provided by Google in dropdown as marked in second encircled area.  We can add here another input claim as last encircled link. Now let’s move to next section that is Then


Here either we can pass through as it is or we can send it in some another type that is available in second encircled drop-down. It has a list of standard claims that we can choose off. Also we can put our own custom claim type in the text box. Every claim type is in URI format as per standard so custom type also should follow the standard. I have selected pass through. The last section is Rule Information . here we can put the details about the rules.

All the required steps has been completed on windows azure portal, Now need to get the metadata for the Federated provider. Click on the Application Integration link under the Development section in left pane.


As this provides many option but we require here WS federation metadata as encircled that will be used in relying party . Copy that encircled URI.

As discussed, I have created a ASP.NET web application project using default template and hosted at IIS. Now the next step to build a trust relationship with Relying party and Federated Provider. So as we have already seen in our part 2 post that how to build relationship between Identity Provider and relying party. We require here the federation metadata from the identity provider and add the STS (Securty Token Service) reference. I am adding those steps for the completeness of the post.

So let us add the STS reference as


It opens a popup as


First encircled area contains Relying party configuration settings and another is Application URI. Click on next


Here as we are using existing STS so selected the last one. We require to provide the metadata here so to get the metadata URL from Federated Provider. I have the provided the metadata URI that we copied from Application Integration section. Click on next


Here I have selected to Disable certificate chain validation as my certificate is not verified. For development purpose it can be disabled but at production, this option should not be selected.  Click Next


Select No Encryption. Click Next.


Here we have two claims Name and Identity Provider. Click Next


Now click finish. And we have built a trust relationship between federated provider and our own Application (Relying Party).

Now it’s time to run the application. So let us run it


It takes us a page and asks us to choose the Identity Providers that we added as Identity Provider while configuring Federated Provider on Azure Portal. The images for Identity Providers, I provided while adding these on Azure Portal.

Now I clicked on Google and it took me at Google login page after providing my credentials and successful authentication, I got redirected my own application as an authenticated user. Similarly can get authenticated via Windows Live Id or Yahoo Id.

Reading Claims provided by Identity Providers

Reading the claims is very easily that are provided by these Identity Providers. I read the claims and displayed it via a Data Control. To read the claims, we can use the following code

IDictionary<string, string> claims = new Dictionary<string, string>();
// Cast the Thread.CurrentPrincipal
IClaimsPrincipal icp = Thread.CurrentPrincipal as IClaimsPrincipal;
// Access IClaimsIdentity which contains claims
IClaimsIdentity claimsIdentity = (IClaimsIdentity)icp.Identity;
gdViewClaims.DataSource = claimsIdentity.Claims;

Now If I login through Google account then it shows the following claims


I have displayed three values here ClaimType, Value, and ValueType.  Here Google returned four Claims which has it’s descriptions and my mail-id and name. Similarly if I login through another Identity Providers, they will show different claims. We can use these values in our relying party for different purposes.

I have written this part is little long (could not make it short). If you face any issue while working on any steps, Do let me know here I’ll be  happy to answer.



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


About the Author

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

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

You may also be interested in...

Comments and Discussions

QuestionNice Article! Customized ClaimType and the switch of STS mode Pin
kimpost23-Sep-13 17:55
memberkimpost23-Sep-13 17:55 
GeneralMy vote of 5 Pin
dgDavidGreene11-Jun-13 21:22
memberdgDavidGreene11-Jun-13 21:22 

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.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170915.1 | Last Updated 10 Jun 2013
Article Copyright 2013 by Brij
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid