Before going on with my other posts I want to introduce you claims-based authentication that makes is way to almost all Microsoft web-based platforms around. It is more complex than old username-password method but also more secure and general. In this posting I will give you short and not very technical overview about claims-based authentication.
What are claims?
Token may contain different claims:
- username or user ID in remote system,
- full name of user,
- e-mail address,
- membership in security groups,
- phone number,
- color of eyes.
System can use claims to identify and describe given user from more than one aspect. This is something you don’t achieve easily with regular username-password based authentication mechanisms.
Claims-based authentication is more general authentication mechanism that allows users to authenticate on external systems that provide asking system with claims about user. The next image from TechNet library page Authentication Patterns illustrates authentication flow simply and effectively.
Here is authentication flow:
- User makes request to some application.
- System redirects user to authentication page of external system (it may also happen after system lets user to select external system where he or she wants to log in).
- After successful authentication external system redirects user back with some information.
- Application makes request to external system to validate user.
- If user is valid then user gets access to application.
Claims-based authentication in practice
Claims-based authentication can be found from many applications:
- Microsoft SharePoint 2010 and 2013,
- Windows Azure Access Control Services (ACS),
- Active Directory Federation Services (ADFS),
- Applications using Windows Identity Foundation (WIF).
This list is not complete, of course, and I am sure you can find more examples from web. About Windows Azure ACS you can read my posting ASP.NET MVC 3: Using AppFabric Access Control Service to authenticate users.
From user information to claims
Not all authentication mechanisms support claims. Take OAuth and Windows authentication as examples. So, how can claims-aware systems use these authentication methods and still provide claims? The answer is simple – we need adapters or proxies that can wrap user information to claims.
This is simplified picture that is here to give you some idea about how user information from other systems is turned to claims. In the case of using adapter directly web application or some component is able to understand one or more authentication mechanisms and wrapping information to claims happens in web application. If you want to be close-to-metal-guy then I can scare you with one of my older blog posts Adding Twitter authentication support to ASP.NET application.
It is also possible to use identity “proxy”. In this case we have token service between our application and external system where user authenticates. This kind of token service is used by Windows Azure ACS. Token service of ACS knows details about different authentication mechanisms and provides your application with token service so your application receives always tokens with claims.
Claims-based authentication is more general authentication system than old and unsecure username-password thing. Instead of saying yes or no about authentication attempt claims-based authentication is wider – external system can give out more information about user by creating claims and putting these into signed token. Although claims-based authentication is new thing it has been around for awhile and in Microsoft world it is trending up. Claims-based authentication is more complex by implementation but it also more secure than yesterday’s authentication mechanisms. Besides SharePoint it lately made its way also to ASP.NET web applications.