June 6, 2012 at 11:01Introduction to Claims-based identity
When developing applications on the Microsoft stack to obtain information about the current user, you can often (almost always) to find information about such sections of code or wrappers above them:
or
The purpose of these calls may be to make a decision about authorizing a call to some function or method, display information about the current user, etc.
User information appeared in these classes in different ways: reading data from the database, Forms authentication, NTLM token, Kerberos token. In each case, the task was solved of obtaining information about the user, his authentication and obtaining additional information.
In “pre-cloudy times” this was quite enough for most applications. If this was not enough, then various kinds of their own frameworks were created, but the main question was often the main question: does the user have a certain role. Until a certain point, this was enough until the user repository was one, there was no need to interact with business partners, etc. With the advent of clouds, distributed systems, SaaS applications and other goodies without which it is difficult to imagine a modern web, this model was not enough if, for example, you wanted to allow your partner’s employees access to certain functions of your CRM. Also often the question arises of the development and evolution of the application, for example:
attributes of the form: a year later, the business decided that it would be nice to have several different user groups with different levels of access and, in addition to (to understand the whole drama of this situation), to differentiate the rights for administrators to SystemAdministrator and SecurityAdministrator. And this is not the limit, since these requirements are limited only by the imagination of the business. From the point of view of the developer, all this resulted in a zoo of technologies and crutches. Each application authenticated users in its own way. The user could authenticate using OAuth, Forms, Windows, or something else. In each particular case, I had to write my own authentication and authorization logic, and if you had Api, then draw a bicycle for it as well.
In response, in 2008, the first release of the Windows Identity Foundation (WIF) was released from the bowels of Microsoft and the concept of Claims-based identity was introduced. The goal of this framework is to provide an abstract mechanism for expressing their requirements for the user without going into the details of how this works.
In short, the idea of WIF can be described with a rather simple life example:
you turned 18 and you decided to go to the cinema. Adult movie. But, unfortunately, they did not manage to get a passport or any other identification card so far (well, or it was just too lazy). You are going and going to the passport office, after some time you receive a passport and, presenting your passport, feel free to buy yourself the coveted ticket and go to the session. And this is how it looks from the point of view of WIF:
Subject, that is, you go to the Identity provider (passport office) and on the basis of Birth CertificateToken you get a PassportToken. Then, with this PassportToken, you go to the Relying party (cinema) and, after confirming your age, get access to the service.
The main ideas that can be drawn from this example:
1. To authorize you, as a visitor to an adult session, the cinema does not need to maintain its customer base or go anywhere. He needs only your ID card that he trusts (Passport, military ID, rights).
2. The passport office does not know where you will present your passport. (From the point of view of WIF, I still need to know a little, but this is not necessary).
3. With a passport, you can buy yourself good whiskey after going to the cinema, take a mortgage or something else at any institution that trusts documents issued by the state. institution.
Someone has already worked with protocols such as OAuth, WS-Trust and WS-Fed, SAML-P and this interaction scheme will be familiar to them. In short, you get information about the user from a trusted Identity provider in the form of a token of a certain format and use it to make any decisions in your application. In a degenerate case, for example Forms authentication, you yourself are this certifying party and yourself use this information. WIF allows such scenarios. WIF is flexible enough to support all sorts of scenarios.
WIF allows you to “outsource” the authentication process to a trusted party and allows you to minimize the need for developer intervention in the authentication and authorization process. All identities that are presented to your application are cast to the ClaimsPrincipal and ClaimsIdentity types. These types are very similar to the standard * Principal and * Identity, they also implement the IPrincipal and IIdentity interfaces, but they have an additional property, which is a collection of all statements that are available to you about the current user. Moreover, for compatibility, various existing methods of working with IIdentity and IClaimsPrincipal are supported, for example: For this, it is enough for the user to have a statement of the role type (you can configure the type of statements that will be used as roles) with the value “Administrators”.
In an application on ASP.NET MVC, it may look like this: Or like this: There are more complex scenarios for checking access to a particular resource, or just getting the user's age, his email address, home phone number. As a result of all these transformations, the Role based security approach is no longer imposed on your application and you are free to choose how, on what basis and where to carry out the necessary checks, as well as, in some cases, completely get rid of the mechanisms for storing user information inside the application. Among other things, you do not care about how the user was authenticated, be it a standard login-password pair or a smart smart card. This is the task of your Identity Provider.
Currently, there are two main solutions for such an approach on Microsoft platforms: ADFS (Active Directory Federation Services) and Azure ACS. If neither one or the other suits you, then you are free to write your own service yourself, as a template with an example is put out of the box into the studio. There is also an open source IdentityServer server on the basis of which you can develop your own product.
Some facts:
Out of the box, WIF supports the following protocols:
1. WS-Federation
2. WS-Trust
3. WS-Security
4. WS-SecurityPolicy
5. WS-Addressing
SAML-P protocol support is in CTP state. There is no information about the RTM version yet. There are also OAuth2 extensions.
The SAML1.1 and SAML2 credentials are standardly supported. But there are already quite developed libraries that add support for SWT and even JWT (Json Web Token).
This was a very small digression into what is happening in the System.Security namespace. As part of the introductory post, I would not want to go into details
By the way, in .Net 4.5, Claims-based identity and WIF become the king of the mountain. All * Principal types will be inherited from ClaimsPrincipal, Kerberos tokens inside will contain a set of statements and much more. If someone is interested in this topic, write your wishes in the comments, as I will surely try to write time.
Useful links:
1. msdn.microsoft.com/en-us/security/aa570351.aspx - MSDN page.
2.claimsid.codeplex.com - Code Samples and a Free Book.
3. leastprivilege.com - Dominick Baier Blog.
4. github.com/thinktecture/Thinktecture.IdentityServer - the open-source the Identity Server.
PS. Thanks to XaocCPS for the review.
HttpContext.User.Identity.Name
HttpContext.User.IsInRole(...)
Thread.CurrentPrincipal.Identity.Name
Thread.CurrentPrincipal.IsInRole(...)
In “pre-cloudy times” this was quite enough for most applications. If this was not enough, then various kinds of their own frameworks were created, but the main question was often the main question: does the user have a certain role. Until a certain point, this was enough until the user repository was one, there was no need to interact with business partners, etc. With the advent of clouds, distributed systems, SaaS applications and other goodies without which it is difficult to imagine a modern web, this model was not enough if, for example, you wanted to allow your partner’s employees access to certain functions of your CRM. Also often the question arises of the development and evolution of the application, for example:
attributes of the form: a year later, the business decided that it would be nice to have several different user groups with different levels of access and, in addition to (to understand the whole drama of this situation), to differentiate the rights for administrators to SystemAdministrator and SecurityAdministrator. And this is not the limit, since these requirements are limited only by the imagination of the business. From the point of view of the developer, all this resulted in a zoo of technologies and crutches. Each application authenticated users in its own way. The user could authenticate using OAuth, Forms, Windows, or something else. In each particular case, I had to write my own authentication and authorization logic, and if you had Api, then draw a bicycle for it as well.
[Authorize("Administrators")]
public ActionResult DoSomeHardcoreAdminStuff()
{
...
}
In response, in 2008, the first release of the Windows Identity Foundation (WIF) was released from the bowels of Microsoft and the concept of Claims-based identity was introduced. The goal of this framework is to provide an abstract mechanism for expressing their requirements for the user without going into the details of how this works.
In short, the idea of WIF can be described with a rather simple life example:
you turned 18 and you decided to go to the cinema. Adult movie. But, unfortunately, they did not manage to get a passport or any other identification card so far (well, or it was just too lazy). You are going and going to the passport office, after some time you receive a passport and, presenting your passport, feel free to buy yourself the coveted ticket and go to the session. And this is how it looks from the point of view of WIF:
Subject, that is, you go to the Identity provider (passport office) and on the basis of Birth CertificateToken you get a PassportToken. Then, with this PassportToken, you go to the Relying party (cinema) and, after confirming your age, get access to the service.
The main ideas that can be drawn from this example:
1. To authorize you, as a visitor to an adult session, the cinema does not need to maintain its customer base or go anywhere. He needs only your ID card that he trusts (Passport, military ID, rights).
2. The passport office does not know where you will present your passport. (From the point of view of WIF, I still need to know a little, but this is not necessary).
3. With a passport, you can buy yourself good whiskey after going to the cinema, take a mortgage or something else at any institution that trusts documents issued by the state. institution.
Someone has already worked with protocols such as OAuth, WS-Trust and WS-Fed, SAML-P and this interaction scheme will be familiar to them. In short, you get information about the user from a trusted Identity provider in the form of a token of a certain format and use it to make any decisions in your application. In a degenerate case, for example Forms authentication, you yourself are this certifying party and yourself use this information. WIF allows such scenarios. WIF is flexible enough to support all sorts of scenarios.
WIF allows you to “outsource” the authentication process to a trusted party and allows you to minimize the need for developer intervention in the authentication and authorization process. All identities that are presented to your application are cast to the ClaimsPrincipal and ClaimsIdentity types. These types are very similar to the standard * Principal and * Identity, they also implement the IPrincipal and IIdentity interfaces, but they have an additional property, which is a collection of all statements that are available to you about the current user. Moreover, for compatibility, various existing methods of working with IIdentity and IClaimsPrincipal are supported, for example: For this, it is enough for the user to have a statement of the role type (you can configure the type of statements that will be used as roles) with the value “Administrators”.
[PrincipalPermission(SecurityAction.Demand, Role = "Administrators")]
static void CheckAdministrator()
{
Console.WriteLine("User is an administrator");
}
In an application on ASP.NET MVC, it may look like this: Or like this: There are more complex scenarios for checking access to a particular resource, or just getting the user's age, his email address, home phone number. As a result of all these transformations, the Role based security approach is no longer imposed on your application and you are free to choose how, on what basis and where to carry out the necessary checks, as well as, in some cases, completely get rid of the mechanisms for storing user information inside the application. Among other things, you do not care about how the user was authenticated, be it a standard login-password pair or a smart smart card. This is the task of your Identity Provider.
[ClaimsAuthorize(ClaimTypes.Role, "Administrators")]
public ActionResult DoSomeHardcoreAdminStuff()
{
...
}
[ClaimsAuthorize(ClaimTypes.Permission, "DoSomeHardcoreAdminStuff")]
public ActionResult DoSomeHardcoreAdminStuff()
{
...
}
Currently, there are two main solutions for such an approach on Microsoft platforms: ADFS (Active Directory Federation Services) and Azure ACS. If neither one or the other suits you, then you are free to write your own service yourself, as a template with an example is put out of the box into the studio. There is also an open source IdentityServer server on the basis of which you can develop your own product.
Some facts:
Out of the box, WIF supports the following protocols:
1. WS-Federation
2. WS-Trust
3. WS-Security
4. WS-SecurityPolicy
5. WS-Addressing
SAML-P protocol support is in CTP state. There is no information about the RTM version yet. There are also OAuth2 extensions.
The SAML1.1 and SAML2 credentials are standardly supported. But there are already quite developed libraries that add support for SWT and even JWT (Json Web Token).
This was a very small digression into what is happening in the System.Security namespace. As part of the introductory post, I would not want to go into details
By the way, in .Net 4.5, Claims-based identity and WIF become the king of the mountain. All * Principal types will be inherited from ClaimsPrincipal, Kerberos tokens inside will contain a set of statements and much more. If someone is interested in this topic, write your wishes in the comments, as I will surely try to write time.
Useful links:
1. msdn.microsoft.com/en-us/security/aa570351.aspx - MSDN page.
2.claimsid.codeplex.com - Code Samples and a Free Book.
3. leastprivilege.com - Dominick Baier Blog.
4. github.com/thinktecture/Thinktecture.IdentityServer - the open-source the Identity Server.
PS. Thanks to XaocCPS for the review.