Claim based Authentication and WIF: Part 2

Introduction

This post is the second part of my post on Claim based Authentication. 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. Let's 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.

Prerequisites

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

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

WIF SDK provides some Visual Studio templates that help 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

The above templates are available in New Website under File Menu.

Let's Discuss an Example

So today, we will create an ASP.NET 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.

Following are the main steps we need to perform:

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

So let's 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

I have created an ASP.NET application as below:

Now as this already created an inbuilt authentication module. You can remove it all because we'll not be using this. Or you can create an empty ASP.NET solution and some page as per your requirement. 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 an STS Reference to ASP.NET website.

• This is the 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 show the following Warning. At Production, all the communication between Identity Provider and ASP.NET website(RP) should happen over SSL only. Here for demo purposes, I didn't use SSL. I clicked on Yes.

• In this screen, it asks to select the STS (Security Token Service). And has three options. 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 STS is not hosted at SSL, 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. 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.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 needs to review and click finish.

Note: Here there is an option to update the federation metadata on a routine basis. One needs 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 not 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:

Let's 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 to the login page that is provided by STS. This is the default login page provided STS, here you don't 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 authenticates every user. Here we can put our code, whether we want to authenticate the user using windows authentication/Form authentication and use database 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 get additional claims here. When you create an STS, there are four files get added in App_Code folder. One file named CustomSecurityTokenService.cs. In this file, there is a method GetOutputClaimsIdentity that 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>
/// <param name="principal">The caller's principal.
/// <param name="request">The incoming RST, can be used to obtain additional information.
/// <param name="scope">The scope information corresponding to this request.
/// <exception cref="ArgumentNullException">If 'principal' parameter is null.</exception>
/// <returns>The outgoing claimsIdentity to be included in the issued token.</returns>
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, "brij@gmail.com"));
    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 applications.

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.