Claim Based Identity - My findings......

Claims - Benefits 

Why we should go forClaim based Identity(defining identity+authorization+authentication), let's have look on couple of noted points which very known:

•Claims-based authentication is not just white (authenticated) or black (unauthenticated). It allows for a whole level of shades of gray. This is where claims augmentation comes into play where, depending upon the level of access you need, you can provide additional claims.

•Claims can be stacked on top of each other. What this means is multiple users with different kinds of authentication can participate on the same web application.

•Claims are Internet ready. Because they use algorithms such as RSA, they are extremely secure and trustable even when you cannot talk to the IP-STS directly.

•Claims do not care about the platform. They are an open standard that everyone understands.

•Finally, there is a complexity surrounding many different kinds of authentications. For instance, if our SharePoint site needs to support Live ID, Google, Facebook and Twitter identities, the implementation and PowerShell scripts for each of these can be a tedious task. Luckily there is Azure ACS, and Azure ACS takes care of handling the intricacies and differences between these various identity providers.

•The user benefits because this should also speed up the process of being granted access to the application or service.

Claims-Work methodology

•The foundation of claims based identity is, as the name implies, claims. A claim, then, is a single piece of information about an individual user that the one making the claim asserts to be true. A specific claim, alone, might or might not be unique to that individual. One claim would be the user’s name, another claim would be his/her age, another would be his/her gender, another would be his/her role in the organization, and so forth. Claims are not just descriptors, however; the user’s right to access a particular server or file can also be represented as a claim.

•All of the claims for a particular user are contained in a security token, which is the complete set of claims information in digital form that is associated with that user.

•Security tokens often (but not always) use SAML (Security Association Markup Language), which is built on the XML standard.

•Tokens are used to transfer the authentication/identity information between the identity provider and the service provider. The token is created and issued by a Security Token Service (STS), which is operated by an identity provider. Obviously anyone could claim anything, so it’s up to the identity provider to verify and then guarantee that these claims are indeed true. The identity provider’s STS serves as an intermediary between the user and the application or service that the user wants to access. Here’s the process:

               1.The user requests to access the application or service.

               2.The application or service sends a request to the STS for a token for that user.

               3.The STS authenticates the user (for example, via a password or smart card or biometric scan.

               4.The STS generates the token.

               5.The STS digitally signs the token and the digital signature becomes part of the token.

               6.The STS returns the token to the application or service that requested it.

               7.The application verifies that the digital signature is valid and that it came from an STS that the application trusts (each   application  will have a list of trusted STSs).

               8.The application processes the claims information to determine whether to allow the user to access the service or   application, and  what level of access the user will have.

What to do

We need to know the supporting environment and how to start with it

•Windows Identity Foundation is a   Microsoft way to leverage the Claim based Authentication. Windows Identity Foundation enables externalize identity logic from their application, improving  productivity, enhancing application security, and enabling interoperability. We can have greater productivity, applying the same tools and programming model to build on-premises software as well as cloud services. We can have greater flexibility in application deployment through interoperability based on industry standard protocols, allowing applications and identity infrastructure services to communicate via claims.

•

Prerequisite:

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

• ■WIF for Win server 2003, Win 7+

• ■WIF SDK

WIF SDK provides some visual studio template that helps 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

 These are following main steps need to perform.

 ■Create a Custom Identity Provider

 ■Create an ASP.NET application

 ■Create a trust between Identity provider and ASP.NET application

If there are several applications available to users and these application trusts several Identity Providers. If user uses an Identity provider that does not trusted by the application. But if there is an one Identity provider trust some another identity provider that in turns trusted by the application. This is called Identity federation. All these above scenario can be easily handled by Identity federation. i e you can have an Identity provider that actually receives (trusts) first the tokens from all the various Identity Providers and then issue a generic token that actually can be understood by the Application. i e the application only trusts the federated provider.

Implementation time

There are couple of factor which will affect the implementation process and time:

–The resource should be well versed with this approach and this technical skill.

–The Identity provider and security token provider should be trustworthy and known source

–This is one way implementation methodology so before taking this approach think twice whether it is required or not.

–It will vary on based on requirement complexity.

–For ideal situation (e.g. few cloud based website need single sign on ) it is very effective solution and great solution which will provide security, platform independence , SSO support, performance and for consumer ease to use.

–Implementation  time will be more or less 20% vary from Form authentication implementation.

Do’s & Don’t

CBA is the concept which looks very nice on paper theoretically but the reality is far away from this. This concept has been developed ideally for cloud environment where we have multiple application running altogether and we wanted to give consumer the facility of “single sign on”.

•Do’s:

–Need to analyze the requirement properly and then think about  this architecture.

–Use existing Frameworks.  

–Choose a standard that won’t change on you at the whim of a vendor

–Adopt a provider that already has a large user base, and then keep it simple

–Perhaps the biggest thing I can recommend is to keep it simple. Start small. Know the providers, and trust the providers

•Don’t:

–Don’t  follow this concept blindly.

–Don’t trust random providers.

–Don’ develop your own framework for this .

Note: Please share your feedback on same.-Rajesh Jha