The new ASP.NET 4.5 code has "re-parented" the ASP.NET RoleProvider to a ClaimsProvider.
What I’m trying to figure out, is what would a "claims based" example of authorization look like (preferably in MVC4)? How does my Authorize attribute interact, or not, with this capability? The WebSecurity and Roles API havn’t changed; there is no "DoesUserHaveClaim()" signature. Similarly, it is not clear how the Authorize attribute interacts with claims.
Was this "claims authorization" feature intended primarily for OAuth? If so, how are claims forwarded to my application? A cookie? Or was this claims-provider functionality intended for a broader use?
In short, what is the story for using a ClaimsPrincipal?
The closest thing I’ve seen to something that kinda makes sense, is this discussion. But I suspect that is dated – it should be compared to what the MVC4 internet project template produces. And even then, it still did not suggest how to use the Authorize attribute with the setup.
UPDATE
I’ve found the answers to my questions from these sources:
- The remarks section of ClaimsPrincipal explains that WebSecurity, Roles, and AuthorizeAttribute APIs do in fact boil-down to claims checks as necessary.
- A claims-based MVC4 example is here (along with others).
- The basic SAML story is shown here.
Claims-based security helps decouple your security model from your application domain. A claim can be anything you want to attach to the identity of the user, such as an email, phone number, or flag indicating whether the user is a super user. This gives you the ultimate flexibility on how you want to setup your authorization process. Historically in an ASP.NET application you have to determine what roles you want to allow and apply them when programming your application. Then you check if the user is in the role to authorize them. This mingles your security model with your application. In claims-based you have much more flexibility and it is more typical to setup an authorization scheme that takes a resource (ex: Orders in an order management system) and an operation (ex: read, write, execute) as input parameters to your authorization process, effectively decoupling security from your application. See ClaimsPrincipalPermissionAttribute for an example of this technique.
Claims-based security is required with OAuth but it works well with other authorization schemes as well. The custom claims you use in your application are accessible from ClaimsPrincipal.Current. There are techniques to store this information in cookies as well, although the ASP.NET security pipeline does not do this by default.
The discussion you reference is for Windows Identity Foundation (WIF) which is now part of .NET in 4.5 and is why claims-based identity is a first class citizen. All of the Principal types inherit from ClaimsPrincipal. For a good overview of claims-based security look at this free ebook “A Guide to Claims-Based Identity and Access Control (2nd Edition)“. A real expert in this area is Dominick Baier and his blog is chocked full of useful information on this topic. He also has a great online training course on Pluralsight called “Identity & Access Control in ASP.NET 4.5“.