Tuesday, October 19, 2010

Intro on Claims Based Authentication

I had a great opportunity to present a future state of authentication that can be adopted on many enterprise applications. Will try to explain some of the authentication related concepts and how that can help on enterprise applications.

If you have read/worked on Windows Identity Foundation or Single Sign on products like PING, you might have heard about claims based authentication. What does that mean? Why is it called claims based? How applications can get anything from this? These are some of common questions that I would try to explain here.
First of all let’s clear on what are some of the key concepts or words that you come across:

Identity - Set of attributes that describe a principal (e.g. an user) such as name,gender, age, email address, driving license number, group membership

If you look at above image, it shows different attributes describes a user/person.

Identity Provider – If you look at real life example and above image, who could be the Identity provider? It will be either any of Government office or any trusted agencies. E.g Passport office

Claims - An attribute about an identity issued by an authority.  Will explain in detail why it is called claim.

Relying party - Application that makes authorization decisions based on claims

Token - A token consists of a set of claims about the principal, and signed by an authority

So why are we calling attributes as claims not as attributes itself? Let’s look at a scenario below. 

If you look at above image, I can have identities on multiple identity providers. And the attributes could be completely different between them. As you can see on the image, age on govt records is 32 while on facebook is 18. As a relying party, if I have to decide based on these attributes, it’s just the Trust depends on scenario not on technical capability

So when I say, user has associated attributes from the identity provider, he is claiming that those are the attributes associated to him and valid. Its upto relying party to decide whether to trust the claims or not.
When the relying party requests the Identity provider to authenticate the user, it authenticates and provides all the user attributes as claims. The token will consist of all the claims that belong to the user. The Security Token Service would be responsible to authenticate the user and provide all the claims as a token.

Most of the authentication concepts on federated authentication, SAML, openID, Oauth are all based on claims. I will try to explain each of them in coming days and how they are different from each other.