Claim based Authentication : Part 4

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.

Continue reading


Claim based Authentication and WIF : Part 2

This post is second part of my post on Claim based Authentication. This part mainly discusses WIF and demonstrates a sample step by step. You all can access my first post from here.

Claim based Authentication and WIF

In my last post I discussed the problems of current day’s authentication implementation, details about Claim based authentication and basic components of Claim based authentication. Now in this post, I’ll discuss about Windows Identity Foundation and the main concepts one by one with a sample.

What is Windows Identity Foundation(WIF):

First of all. I’ll say Windows Identity Foundation is a   Microsoft way to leverage the Claim based Authentication. Lets see the definition from msdn,

Windows Identity Foundation enables .NET developers to externalize identity logic from their application, improving developer productivity, enhancing application security, and enabling interoperability. Enjoy greater productivity, applying the same tools and programming model to build on-premises software as well as cloud services. Create more secure applications by reducing custom implementations and using a single simplified identity model based on claims. Enjoy greater flexibility in application deployment through interoperability based on industry standard protocols, allowing applications and identity infrastructure services to communicate via claims.

So we can say, Windows Identity foundation provides a set of classes which facilitates in implementing Claim based authentication.


To use WIF you need Windows 2003 server+ or Windows 7/8/Vista.

  • WIF for Win server 2003 download it from
  • WIF for Win 7+ download it from
  • WIF SDK download it from

WIF SDK provides some visual studio template that helps in developing Claim
aware applications. These templates are

  • ASP.NET Security Token Service Web Site
  • Claims-aware ASP.NET Web Site
  • Claims-aware WCF Service
  • WCF Security Token Service

Above templates are available in New Website under File Menu.

Let’s discuss an Example

So today we will create an application(Relying Party Application-RP). And also
we’ll create a custom
Identity provider and we’ll use this identity provider for authentication of the user.

These are following main steps need to perform.

  • Create a Custom Identity Provider
  • Create an ASP.NET application
  • Create a trust between Identity provider and ASP.NET application

So lets first create an Identity Provider

Creating a Custom Identity Provider

So here I will create a step by step process to create a Custom Identity Provider.

– Open Visual studio-> Create new website ->select ASP.NET Security Token Service Web Site (I have selected the location HTTP
to host it at IIS directly)

Now your sample Identity provider is created. It provides the basic infrastructure for you. It includes one login page that actually authenticates the user and here forms authentication is used.

Create an ASP.NET application( Relying Party – RP):

I have created an ASP.NET application as below.

Now as this already create a inbuilt authentication module. You can remove it at all because we’ll not be using this. Or you can create an empty solution and some page as per needed. I have removed the account folder for the demo.

Create a trust between Identity provider and ASP.NET application(RP): This can be done using FedUtil provided by WIF SDK. Also from UI, we can add an STS reference in the ASP.NET website and make a trust relationship between Identity Provider and Relying Party. Look the following steps to add the reference

  • Add a STS Reference to ASP.NET website

  • This is First screen of FedUtil which displays the URI and location of ASP.NET website(RP)

  • If you have not hosted your ASP.NET website(RP) on SSL it will the following Warning. At Production all the communication between Identity Provider and ASP.NET website(RP) should happen over SSL only. Here for demo purpose, I didn’t use SSL. I clicked on Yes.

  • In this screen, It asks to select the STS ( Security Token Service). And has three option. As we have created the STS, we need to select the option “Use an existing STS”

To build the trust relationship, we need to provide the federation metadata provided Identity Provider.

  • Now we need to browse the FederationMetada xml file of the STS that we created.

FederationMetadata file resides in a special folder hierarchy “FederationMetadata/2007-06” under the STSWebsite physical folder.

  • And Select the FederationMetdata. And Click next

  • Again as my Security Token Service(STS) is not hosted at SSL. So it is showing the below warning
    message. I just clicked Yes

  • Here it asks if one wants to encrypt the token. It should be encrypted on production.You require to provide a certificate for the encryption. Here I have selected the option “No Encryption” for the demo.

  • Now it shows all the claims passed by STS to RP. We can pass more claims from STS to RP as per our requirement. All the Claims is shown here while adding the STS reference at end. By default there are only two roles provided by STS (Name & Role)

  • This is the Summary screen, shows the details about STS and RP. One need to review and click finish.

Note: Here There is an option for to update the federation metadata on a routine basis. One need to know, if the STS is getting changes say Token or Claims etc. RP would only come to know about when federationmetadata will be updated, else say if someone removed a Claim and metadata is not updated it will allow to get the that Claim but actually at runtime you would nto get that claim which will not be a good condition.One should always have the metadata in updated form.

After clicking Finish. A folder FederationMetadata is added to ASP.NET website (Relying Party -RP) as below

Lets run the application:
Now if you run the application. It will throw an exception as

“Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.”

This is an issue with it and I have made a small post on it. You can get it resolved easily. Please check this

Now after changes it will run smoothly and It will take you at login page that is provided by STS. This is default login page provided STS, here you dont need to write password just put some name and click on login as below.

It will redirect to another page to STS which will actually initiate the process to create the token and claims. Then after creating it will be transferred to your website as authenticated user.

Now our application is running. As here in STS we have a sample login page the uses Forms authentication and by default authenticate every user. Here we can put our code, whether if we want to authenticate the user using windows authentication/Form authentication and use database this all we can and also we can get some data of the user from any store say DB here and that we can send using in Claims as per our requirement.

So Now here I’ll show, how to pass some more information to the user in Claims. So one can additional claims here. When you create a STS, there are four files get added in App_Code folder. One file named CustomSecurityTokenService.cs. In this file there is a method GetOutputClaimsIdentity actually creates the claims. We need to add the claims here ( I have added few)

<summary> /// This method returns the claims to be issued in the token.
 /// </summary>
    ///The caller's principal.
    ///The incoming RST, can be used to obtain addtional information.
    ///The scope information corresponding to this request.
    /// If 'principal' parameter is null.
    /// The outgoing claimsIdentity to be included in the issued token.
    protected override IClaimsIdentity GetOutputClaimsIdentity( IClaimsPrincipal principal, RequestSecurityToken request, Scope scope )
        if ( null == principal )
            throw new ArgumentNullException( "principal" );
        IClaimsIdentity claimsIdentity = (IClaimsIdentity)principal.Identities[0];

        ClaimsIdentity outputIdentity = new ClaimsIdentity();

        // Issue custom claims.
        // Update the application's configuration file too to reflect new claims requirement.

        outputIdentity.Claims.Add( new Claim( System.IdentityModel.Claims.ClaimTypes.Name, principal.Identity.Name ) );

        outputIdentity.Claims.Add(new Claim(ClaimTypes.Role, "Manager"));
        //I added these custom claims
        outputIdentity.Claims.Add(new Claim(ClaimTypes.Email, ""));
        outputIdentity.Claims.Add(new Claim(ClaimTypes.Gender, "Male"));

        return outputIdentity;

I have added two claims (Email, Gender )as above. These Claims will be available at ASP.NET website( Relying Party).
The same Identity provider can be used in multiple application.

Reading Claims at Relying Party(RP):

It’s easy to read the claims at Relying Party. To read the claims you need ClaimsIdentity of the logged in user and it is available in User Property. I have read the Claims at my page. I have created a dynamic table and shown the claim in that.

          IClaimsPrincipal claimsPrincipal = Page.User as IClaimsPrincipal;
        IClaimsIdentity claimsIdentity = (IClaimsIdentity)claimsPrincipal.Identity;

        // The code below shows claims found in the IClaimsIdentity.

        Table claimsTable = new Table();
        TableRow headerRow = new TableRow();

        TableCell claimTypeCell = new TableCell();
        claimTypeCell.Text = "Claim Type";
        claimTypeCell.BorderStyle = BorderStyle.Solid;

        TableCell claimValueCell = new TableCell();
        claimValueCell.Text = "Claim Value";
        claimValueCell.BorderStyle = BorderStyle.Solid;


        TableRow newRow;
        TableCell newClaimTypeCell, newClaimValueCell;
        foreach (Claim claim in claimsIdentity.Claims)
            newRow = new TableRow();
            newClaimTypeCell = new TableCell();
            newClaimTypeCell.Text = claim.ClaimType;

            newClaimValueCell = new TableCell();
            newClaimValueCell.Text = claim.Value;




and now when you run the page it will be shown like

Now you can see that it is very easy to read the claims and this can be used in further processing.

I hope the above sample will help a lot. In my new post of this series. I will discuss another technique to implement use Claim based Authentication which is widely Used Called Identity Federation.

Thanks a lot

Claim based Authentication and WIF : Part 1


There is a lot of buzz about Claim based Authentication. In this article, we’ll understand what is Claim based Authentication? What are the benefits and lot more.This is first Postin this Series. In subsequent posts, We will the implementation and more scenarios.

Let’s first understand, what is the need of Claim based authentication?

Problems with Current Authentication Mechanism

As we used to make several user accounts at several portals/websites. So every time we need to access the corresponding website, we need to remember usrename and password and if somehow we forget the password then we need to remember some specific details like security question etc to get the access of the account again. And every time we might not remember all these details. Also It is never advisable to write your user credentials physically.

One more problem, Most of the applications are using some authentication mechanism mainly Classic UserName and Password. As most of developers are not really security experts they use to leave loopholes during development which are easy to break. So it is a major security risk.

Most of developers have some or other day have worked SingleSignOn feature. It’s not always been a simple task. It leads a lot of challenges and many issues after the application is deployed on UAT/Production.

As a user, we create a new user credentials (username and password) to lot of many application on internet like facebook, yahoo, gmail etc and some in-house site like some college portal etc or some enterprise application. So create every time a new credentials and to remember all these credentials and all are secured enough is very tedious. If there is any error you might loose some credentials and could end up in a big loss.


Imagine the situation where you just need to have one user credential ie username and password and that is enough to access all your portals/websites. This will be Ideal situation. Might be it could not take place completely, but we are somehow moving in this direction.

But how can this take place?

Actually Now a days when we create a Application which has authentication page, we need to understand, how it works. Actually when user logs in an Identity is assigned to that session and that Identity is maintained throughout the session until user logs out or it expires. So let’s view the current scenario.

Means every application which has some authentication mechanism first authenticates the user and gives an Identity and then user gets the rights to access the application. So somehow if we can externalize the authentication part from the application then this will be very helpful and the same authentication application used by several application. I explain it pictorially

So the basic Idea is, If there are some applications that do the authentication and provides the Identity (Called Identity Provider), and applications rely on this Identity. Like in our daily life

Above picture explains everything about itself.

Claim Based Authentication

The same mechanism is also followed in Claim based Authentication. There are some authentication provider/Identity provider which are used by various applications so whenever a user tries to access some application, Application checks whether user is authenticated or not, if not, it forwards the user to Identity provider which actually authenticates the user, gives a token to user and forward the user to application. Application verifies the token and user is allowed to access the application.

But this is not so easy in web scenario. There are few challenges – Who are the Identity Providers? – What all the data is needed to the relying party ie what data can be transferred from Identity provider and in which form – If there are multiple Identity providers. How application trust on them.

Actually there are couple of Identity providers nowadays like Google, facebook, WindowsLive Id and many more.. And even we can develop our own Identity provider for on premise applications. This also can be used on Cloud as well.

Now if I am making an application and my application uses some Identity provider to authenticate a user. Then application must understand the token of that Identity provider and also there must be trust relation between application and Identity providers, so that application can rely on the token sent by that Identity provider.

Basics of Claim based Authentication

Now let us discuss what are the basic things involved in it. These are mainly Identity, Tokens, Claims, Identity Provider or Security Token Service, RP (Relying Party) etc. To move ahead we need to understand all these. Lets discuss one be One.

What is an Identity

You can say Identity is a group of information that can uniquely identify anything. Most of the other things also have identity like your own PC, Vehicle etc. But here as we are talking about person. So in this digital era, we can say a digital identity is a group of information to identify a person.

Token and Claims

When this digital identify is passed over wire. It is passed as stream of bytes and that is known as token. Token contains some set of Information about the user in the Claim format. A token can contain multiple claims and every claim contains some specific information. The token is digitally signed so that it can be verified at receiver end. So we can show the pictorially as

Sometimes token be XML based Security Assertion Markup Language (SAML) format. But now application use rather simpler token call as Simple web Token( SWT). So the benefit is here we just not pass user credential but also we can pass some other information of the user to the application.

Identity Provider and STS

Identity provider is the key in this technology, this is actually authenticate the user and create the token with claims, as per the requirement and digitally sign it before sending. Identity provider is also known as Security token service. So how STS work lets have a view.

RP (Relying Party)

Relying party are the applications those uses these Identity Provider for authentication. They just need to understand and verify the token and get all the data from the token itself which is required. But before all this, RP needs to build a trust relationship and tell the Identity provider what all data needs for a user. So that next time a token it receives, it can verify the issuer and get the required data.

Complete Scenario

Now you guys got all the basic information about Claim based Authentication. Now let us have a look, how these Identity provider is used

So this is the basics of the Claim based Authentication and in my Next Post we’ll focus on Implementation part with the help Windows Identity Foundation WIF.

Do share your views about this post and let me if I have missed anything.