Implementing Claim Based Authentication

Implementing Claim Based Authentication

As we all know, Claim based authentication is the future authentication strategy; the obvious question which comes to mind is -

How to implement Claim based authentication? Or How to implement Claim based identity? Or how to configure claim based identity?

However, before going forward I will highly recommend that, you should understand the terminology like Identity Providers, Secure Token Services, Identity and access management and Claim based authentication.

Today I will discuss the generic steps to implement Claim based authentication. I am referring Microsoft Pattern and Practices – A Guide to Claim-based identity book for explanation.

Total there are 4 generic steps to be followed for implementing claim based authentication –

1.   Add logic in your application to for supporting claims –

When you are planning to build claim based application, application needs to know how to validate security token coming from security token service and how to retrieve claim from that security token. Microsoft has given rich classes in a framework to handle implement claim based application. This framework is Windows Identity Foundation (WIF). Windows identity foundation provides basic programming model for claim based authentication. This WIF can be used for Windows Communication Foundation (WCF) to “secure web services” and also can be used with ASP.Net applications.  In order to use WIF, you will need to add reference to WIF assembly (Microsoft.IdentityModel.dll) in WCF or ASP.NET application.

2.   Acquire or build an issuer –

In most of the enterprise applications, the easiest and most secure way to get issuer of token is ADFS 2.0 (Active Directory Federation Service 2.0). In case of you want to handle great deal of security in your application, you should seek help of experts to get an issuer of security tokens. In this case you will need to WIF.

3.   Configure your application to Trust the Issuer –

Once you have developed a claim based application using WIF and have an issuer to issue security token, the next step is to set up a trust relationship. This is very important step. An application needs to trust the issuer to identify and authenticate users and make claims about their identities. When you configure an application to rely on a specific user, you are establishing a TRUST (or TRUST RELATIONSHIP) with that issuer. You will need to cover following important points –

·         What claims does the issuer offer?

·         What key should the application use to validate the signatures on issued tokens?

·         What URL must user access in order to request a token from the issuer?

Most of the standard issuer offer claims with common required information. The answer to above three questions can be obtained from the issuer by asking for “federation metadata”. This is the XML document which issuer provides to application. This is an XML document that the issuer provides to the application. It includes a serialized copy of the issuer’s certificate that provides your application with the correct public key to verify incoming tokens. WIF includes a wizard that automatically configures your application’s identity settings based on this metadata. You just need to give the wizard the URL for the issuer you’ve selected, and it downloads the metadata and properly configures your application.

4.   Configure the issuer to know about your application –

The issuer needs to know a few things about an application before it can issue it any tokens:

·         What Uniform Resource Identifier (URI) identifies this application?

·         Of the claims that the issuer offers, which ones does this application require and which are optional?

·         Should the issuer encrypt the tokens? If so, what key should it use?

·         What URL does the application expose in order to receive tokens?

When a client requests a token, part of that request includes an identifier for the application the user is trying to access. This identifier is a URI and, in general, it’s simplest to just use the URL of the application, for example, http://www.test.com/sell/.

If you’re building a claims-based Web application that has a reasonable degree of security, you’ll require the use of SSL (HTTPS) for both the issuer and the application. Applications with stronger security requirements can also request encrypted tokens, in which case, the application typically has its own certificate (and private key). The issuer needs a copy of that certificate (without the private key) in order to encrypt the token issued for that application.

Once again, federation metadata makes this exchange of information easy. WIF includes a tool named FedUtil.exe that generates a federation metadata document for your application, so that you don’t have to manually configure the issuer with all of these settings.

If you see I have outlined the high level steps to configure an application for claim based authentication. However, the above steps are very complex to implement and required great amount of expertise.

So what is the solution? – The solution lies in Windows Azure Appfabric ACS.

Click on the following link to go to ACS article - Windows Azure Appfabric Access Control Service (ACS). (Yet to Come)

Cheers…

Happy Programming!!