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)

Followers

About Me

I am Kunal Chandratre. Working as Cloud Solution Architect @Microsoft. My speciality is Microsoft Azure Cloud platform.
Awarded as Most Valuable Professional (MVP) in Microsoft Azure for consecutive 3 years. Passionate speaker, trainer...In free time (which I don't get usually)I write blogs and answers the forum questions. I was doing it just for timespass but now I have got addicted to blogging...Apart from work, I do variety of things which I can't tell here:).. I am trekker, singer, actor, painter, f1 racer, super hero in my dreams.. ...and now trying my luck with technologies...Keep posting...

Visitors

Disclaimer:

The information shared in this blog is the result of my personal experience with various technology platforms. In no way it represents the company I work for.
The information provided here is "AS IS" with no warranties, and confers no rights. This blog does not represent the thoughts, intentions, plans or strategies of my current employer or past empolyers or any other forums or community I belong to. It is fully my own opinion. Inappropriate comments will be deleted at the authors discretion. All code samples are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.I have full rights to edit/modify/delete any content of this blog without any prior notice to public/followers/RSS readers of this blog.