Programming Microsoft ASP.NET 4 - Dino Esposito [429]
The key idea behind claims-based identity is that an application (and not just an ASP.NET application) uses a third-party provider that assumes responsibility for returning a few true statements about a user. These statements are known as claims. The calling application gets the list of claims and, based on that, decides which sections of the site should be unveiled to the user and which features should be enabled.
For developers, the biggest change is that you don’t include in your codebase anything that deals with authentication and authorization. You simply arrange a conversation with an external identity provider, tell it about the statements you’re interested in verifying, and wait for a response. The user is redirected somewhere else (presumably to the identity provider site), provides requested credentials, and gets authenticated.
So, in the end, it is still about having a piece of code that collects and verifies credentials, isn’t it? Ultimately, it has to be this way because this is the only way in which authentication works. As a developer, though, you just outsource authentication to an external provider that you trust and that you have explicitly selected.
The Authentication Workflow
Figure 19-7 illustrates the typical workflow that characterizes a claims-based authentication process. The user initially connects to the application and attempts to log in. If all goes well, the user is ultimately redirected to the requested (and protected) page—nearly the same as in the authentication process we just reviewed. However, everything else is different under the surface.
Figure 19-7. The typical flow of claims-based authentication.
An application designed to take advantage of claims-based identity redirects the user to the identity provider of choice. The user interacts with the site of the provider and enters any information that the provider reckons to be useful to authenticate the request. If the operation is successful, the identity provider issues a security token and redirects back to the application. The security token that is then handed over to the application contains claims about the user. These claims are trusted by the application.
Claims and Policies
So a claim is nothing more than a statement that has been verified by the identity provider, and the identity provider guarantees it is true. What kind of statements are we talking about, however? A claim is strictly bound to the provider. Different providers can issue different claims, and not all providers can validate a given claim.
A canonical example often discussed to introduce the concept of a claim is an online wine shop that needs to be sure about the age of the people placing orders. In this case, the classic approach of having users register with the site, provide a birth date, and proceed with purchasing products doesn’t work. Who can reliably prove that the user is really of the legal age for purchasing alcohol? Certainly not the user himself!
In a claims-based system, the wine shop application might rely on an identity provider that “claims” to be able to verify the age of a user. The provider can ask for a driver’s license number and cross check that number with the database of the Driving and Licensing department. Any identity provider must expose a policy document that lists its requirements (protocols, endpoints, data formats) and the list of claims it can support. An application must likewise incorporate a policy document with the list of security requirements—facts the application needs to know for sure in order to proceed. Furthermore, the application must include a list of valid and trusted providers.
Issued by the identity provider, a security token travels the network to reach the requesting application and carry information. The security token is digitally signed, can’t be tampered with, and can be related to the issuing provider.
Strictly related to identity providers are the Security Token Service (STS). An STS provides a standards-based method of authenticating users and completely