37

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:

  1. The remarks section of ClaimsPrincipal explains that WebSecurity, Roles, and AuthorizeAttribute APIs do in fact boil-down to claims checks as necessary.
  2. A claims-based MVC4 example is here (along with others).
  3. The basic SAML story is shown here.
Community
  • 1
  • 1
Brent Arias
  • 26,187
  • 32
  • 120
  • 209

1 Answers1

33

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".

Patrick
  • 16,618
  • 5
  • 65
  • 82
Kevin Junghans
  • 17,102
  • 4
  • 42
  • 60
  • I'm not sure if the new model truly makes "less mingling" of my application with security (I'm still decorating attributes on methods), but it certainly provides more fine-grained control. Also, the ASP.NET roleManager does have a means to store principal info (i.e. roles and presumably claims) in a cookie - virtually by default if turn it on in configuration. Most importantly, thank you for the information you've given, marked as answer. – Brent Arias Nov 19 '12 at 22:52
  • 2
    Although you are still putting attributes on the methods in the new model you are only indicating what resource is being acted upon and the type of operation, which is not specific to any security design. The old model made you think of what roles should be available when adding the attributes, which is very specific to your security design. In the new model you can change how users are authorized without going in and changing those attributes. – Kevin Junghans Nov 20 '12 at 13:56
  • 1
    In a ClaimsPrincipal the user name and roles are default claims. These two types of claims are automatically stored in a cookie. But for custom claims there is some custom coding you need to do make sure they are stored in the cookie. – Kevin Junghans Nov 20 '12 at 13:59
  • 1
    Just to provide an update to this answer, it looks like claims are automatically stored in the cookie with ASP.NET MVC 5. – Justin Helgerson Feb 12 '14 at 21:00