Claims based authentication(Basic details)

In this article, I am trying to explain some basics of new claims based authentication with live scenario.

First of all, what are authentication methods are available?


ASP.NET when launched supported 3 types authentications namely:

1.     Windows Authentication (better for Intranet scenarios and credentials are stored inside Active Directory),

2.     Passport Authentication (Now Live ID Authentication, can be used   via Claims Based Authentication).

3.      Form Based Authentication (where user data is maintained inside SQL Database).

 

ASP.NET 2.0 provided some tools and classes and made FBA much simpler. It automatically created required tables, stored procedures, UI to manage Users (Membership Providers), their access rules by their roles (Role Provider) and store some more data about users (Profile Provider).


In the Microsoft world, authentication is usually performed by Active Directory. I claim to be Arvind, and i prove this to Active Directory by providing my password. Other systems don’t trust me, they trust Active Directory.

Active Directory gives systems a bit of data that says “yeah, I personally know this person. It really is Aravind.”

In single environment Claims based authentication is not needed.

But, Privacy regulations are impacting what kind of information capture and store about user. Because, in some case user do not want to give his personal information.

And one more case is that, In case of merging two sites, then if both are having different authentication type, then it becomes a mess.

In this case, if claims based authentication has implemented, then it can handle both with a common method.


Scenario: 


Suppose, I am having liquor online shop purpose to sell liquor direct to the customer. So my company service is to provide imported liquor to customer’s hand without any intermediate. I am having one website called myliquor.com. So customer can place his order over the net. But According to Law of Indian government, liquor should not sell to the people whose age is lesser than 18.


But, I don’t know whether the person who is placing order is eligible or not. So what I will do is, I will ask to government to provide some identity (token) that will ensure about customers age. Consider I will use the voter id login service from the government. So that it can tell the age of a customer.

By doing this, No need to maintain customer’s personal information for me. Also No need to check the age eligibility for me.


Best Example: while using the CRM 2011 online, we have use windows live id. Here CRM online get tokens from windows live.




There are several components to claims authentication. The STS(identity provider) that issues the tokens to entities. An application makes decision by consuming these tokens.


In between, identity provider and application there is a federation provider manages trusts for application and translates token containing claims in such a way that application can understand.

 

Classical authentication approach means, that every application has its own authentication mechanism that       leads to many different problems.

One of the most important problems of this approach is       dispersion of user identity. Each application holds its own copy of user’s data which is used to build user identity. This kind of approach does not fit for single sign on authentication.

Nowadays, mechanism called SSO is becoming more and more popular due to possibility for allowing authentication in many applications using one application of user identity. User logs once (authenticates and authorizes) and gains access to all systems without being prompted to log in again.



In next article, I will explain how we set claims based authentication.

 

Comments

Popular posts from this blog

Wrapping information in a symbol-Microsoft Tag

Best Ways For WCF Exception Handling

Making Offline MVC 3 Application.