Claim Based Authentication

Problem with current authentication

We make several user accounts at several portals/websites. Every time we need to access the corresponding website, we need to remember the username and password to get the access of the account again. And every time we might not remember all these details. Also, it is never advisable to write your user credentials physically.

One more problem, most of the applications use some authentication mechanism, mainly Classic UserName and Password. As most of the developers are not really security experts; they leave loopholes during development which are easy to break. So it is a major security risk.

As a user, we create new user credentials (username and password) to many applications on the internet like Facebook, Yahoo, Gmail, etc. and some in-house sites like some college portal, etc. or some enterprise application. So to create new credentials every time and to remember all these credentials and see that all are secure enough is very tedious. If there are any errors, you might lose some credentials and could end up in a big loss.

Solution

Nowadays, when we create an application which has an authentication page, we need to understand how it works. Actually when user logs in, an Identity is assigned to that session and that Identity is maintained throughout the session until the user logs out or it expires. So let’s view the current scenario:

So the basic idea is, if there are some applications that do the authentication and provide the Identity (called Identity Provider), and applications rely on this identity, like in our daily life:

Claim Based Authentication

The same mechanism is also followed in Claim based Authentication. There are some authentication/identity providers which are used by various applications whenever a user tries to access some application. The application checks whether the user is authenticated or not, if not, it forwards the user to the Identity provider which actually authenticates the user, gives a token to the user and forwards the user to the application. The application verifies the token and the user is allowed to access the application.

Now if I am making an application and my application uses some Identity provider to authenticate a user, then the application must understand the token of that Identity provider and also there must be trust relation between the application and Identity providers, so that the application can rely on the token sent by that Identity provider.

Basics of Claim based Authentication 

The basic things involved in claim based authentication are:

1. Identity: You can say Identity is a group of information that can uniquely identify anything. A digital identity is a group of information to identify a person.
2. Token and Claims: When this digital identify is passed over wire, it is passed as a stream of bytes and that is known as token. Token contains some set of information about the user in the Claim format. A token can contain multiple claims and every claim contains some specific information. The token is digitally signed so that it can be verified at the receiver end.
3. Identity Provider & STS: Identity provider is the key in this technology, this actually authenticates the user and creates the token with claims, as per the requirement and digitally signs it before sending. Identity provider is also known as Security token service.
4. Relying Party: Relying party are the applications that use these Identity Providers for authentication. They just need to understand and verify the token and get all the data from the token itself which is required. But before all this, RP needs to build a trust relationship and tell the Identity provider what all data is needed for a user. So that next time it receives a token, it can verify the issuer and get the required data.

About Author:
Lovina Dodti is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at lovina.d@spluspl.com