Overview: Using Claims-based Access on Windows Azure

Introduction

In this blog, I would like to talk about a technology which will simplify user access for developers by allowing building claims-aware application: Windows Identity Foundation (WIF). The goal is to improve developer productivity, enhance application security, and enable interoperability. For most of us, claims-aware authentication is nothing new, the new part I’m writing about is how to implement it in Windows Azure environment. If you already developed some solutions with WIF and also know what claims-based identity means, you can save some reading and jump directly to the Windows Azure section.

Background

Authorization and authentication is a very important aspect of any software solution. But somehow, many software solutions are not good enough designed to protect private or important data against attackers.

Many applications have their own user identity store developed into their business layer, where it has to be maintained and supported along with the application by developers. I’m not saying that every solution is like this in the world, there are many examples of centralized authorization and authentication solutions, but as we are entering another era, where we are moving our solutions to Windows Azure, it is becoming clear to us that our security solutions does not provide the required scalability and extensibility.

Claims-based Solution

Thanks to Windows Identity Foundation (WIF), we have the option to stop writing our custom identity plumbing and user identity databases for every application using .NET Framework. So, what is claims-based identity? I’ll try to explain it briefly; the following diagram shows a simple and classic authentication implementation:

The client enters user name and password (1) to get access to the secure area. The data is passed to the security layer (2), where the credentials are validated against a user identity store (3). Then the result is most probably returned in the form of some user claims (4) and passed to the application (5). The term “Claims” is used here in order to express that the data returned from the identity store has also more than just user properties. A claim can be a user’s email address, department, etc. But claims are a little more than just user properties; claims include trust information about the provider too. At the end, the client may receive access to the secure data (6).

Windows Identity Foundation

There is nothing wrong with this picture until you want to implement a different security, enhance your security or add one more application to your system. The problem is that you have to modify your code based on identity and security. Claims-based identity allows you to decouple this logic from the heart of your application and give the responsibility to another entity. That entity is the Identity Provider, as seen below:

The client starts with requesting the token requirements from the application (1), receives them (2) and passes them to the Identity Provider’s Security Token Service (STS) along with the user name and password (3). The STS validates the user information against the user identity store (4) and receives the token answers in form of claims (5). Then it passes the token along with the claims and a public key back to the client (6). The client forwards the token to the application. The application uses (8) WIF to resolve (9) the token (Canonicalization, Signature checking, Decryption, Check for expiration, Check for duplication, etc.) and maybe receives the claims it requires out of the token (10) if the token is valid. At the end, the client may receive access to the secure data (10).

At first glance, it looks like we are introducing a lot of steps (from 6 to 11), but when you think about the simplicity of the code you have to write to authenticate a user in your application, using WIF saves a lot of trouble. For example, the only code I have to write to get a claim looks like this:

protected void Page_Load(object sender, EventArgs e)
{
    IClaimsIdentity claimsIdentity = 
	((IClaimsPrincipal)(Thread.CurrentPrincipal)).Identities[0];
    String userEmail =
        (from c in claimsIdentity.Claims
        where c.ClaimType == System.IdentityModel.Claims.ClaimTypes.Email
        select c.Value).FirstOrDefault();
}

In this code, we are accessing the instance of our claims identity and querying the claims for the email address, which is a claim from a token generated by the STS. The rest is only application configuration. For example, in a very simple implementation, we could only setup some pages to be seen by a certain role and make the following configuration:

<location path="SecretPage.aspx">
<system.web>
<authorization>
<allow roles="Manager"/>
<deny users="*"/>
</authorization>
</system.web>
</location> 

Please check out the SDK and Toolkit links below, you will really enjoy the practicality of this framework.

Practicality is not the only advantage; it is also powerful when we want to implement different authentication technologies. For example, switching to use active directory will not require any code changes on your application as well as on the communication to your application as seen below:

Having said that, I would like to introduce you to the other parts of the Microsoft’s Identity and Access Platform software family: Active Directory Federation Services (ADFS) 2.0 and Windows CardSpace 2.0. You can get more information about these technologies here. I’ll not get into the details of ADFS and CardSpace because it is outside our current scope, but those are nice technologies which you may use for your custom solution.

Customization

You can also develop your own custom STS with the help of the Windows Identity Foundation SDK. Creating a custom STS is as simple as right clicking your project, selecting “Add STS reference…” and following the wizard to create a new STS project. For more information, you can download WIF and WIF SDK from these links:

• http://www.microsoft.com/downloads/en/details.aspx?FamilyID=eb9c345f-e830-40b8-a5fe-ae7a864c4d76&displaylang=en
• http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c148b2df-c7af-46bb-9162-2c9422208504&displaylang=en.

And please do not forget the Toolkit from here, which provides all possible code examples you would need. Just a note: Please start first by setting up your environment as described in the Setup.docx in the Assets folder of the toolkit. I’m one of those who reads the manual last, you can save time until that point. :)

Windows Azure

Now, how will all this help us on Windows Azure platform?

There are many scenarios you can start using Windows Azure platform as a part of your solution. One of them is to place your application to the cloud and keep your STS on-premise. In this way, you can still take advantage of local identities for authenticating your users and take advantage of Windows Azure features like load balancing, scalability, etc. The following diagram shows this example:

The logic is very similar to the previous one; the client connects to the application (6) only after sending the application (in this case, an ASP.NET web application on an ASP.NET web role) a token (5) which was gathered from the identity provider (4) based on the requirements defined by the application (2). I did not draw the details of the identity provider and application because it can vary as I described in the claims-based identity scenarios. Please notice that the WIF is still used in the application on the Windows Azure. But, WIF is not in the Windows Azure GAC which is visible to the Windows Azure applications. Therefore, I wanted to point it out that it is manually referenced.

One of the important details is to know that the application hosted in Windows Azure can have a different URI because of development, testing and production environments. Therefore, the application’s URI should be dynamically embedded into the token for reply. As a result, the STS also has to be modified to validate the reply URI.

Another detail is to establish a trust relationship between the ASP.NET Web Role and the STS. That is simply done with the wizard which shows up when you right-click on your application project and select “Add STS reference…”.

One other key scenario is to also to delegate the Identity providing part to Windows Azure. That is by using the Windows Azure AppFabric Access Control technology instead of our STS.

The usage of AppFabric Access Control is shown in the following diagram:

As you can see, the claims-based workflow is not changed much; I only simplified the communication (1) just for clarity purposes. The SWT stands for Simple Web Token.

You can get more details about this scenario from the WIF toolkit labs here.

Conclusion

Using claims-based access solutions simplifies a project in many aspects like maintenance, security, extensibility, etc. Having this technology applied to the cloud expands our endless solutions space in another dimension. I only scratched the surface of this nice technology, please go ahead and check out the resources I pointed in this post. I hope you will enjoy it as much I did.

CodeProject