The Joy of Excellence

ClaimAuthorizeAttribute

Headline: Here is what I use for authorizing controller and actions in an MVC application that uses the new Claims based authorization.

Some Great Resources

Before I even begin, let me point people to some great resources I found today on this topic. The first has so many posts on the topic and they are well written. Check out the Claims based security section:

http://dotnetcodr.com/security-and-cryptography/ by Andras Nemes (Stockholm, Sweden)

The second has quite a few resources too.

http://leastprivilege.com/2012/10/26/using-claims-based-authorization-in-mvc-and-web-api/ by Dominick Baier (Heidelberg, Germany)

Motivation

I spent lots of time looking at claims based security as the new WIF (Windows Identity Foundation) 4.5 has rolled out.

There is an attribute called ClaimsPrincipalPermission that I thought would do the trick. However, I’m not impressed. I’d love to delete this post if someone can show me what I’m doing wrong.

So the usage would be something like:

[ClaimsPrincipalPermission(SecurityAction.Demand, Resource = “Salary”, Operation = “Edit”)]

Now, suppose you have a claims system where you have addresses and salaries as resources. And some people can view both, but only edit the address.

I thought that you had name/value pairs like you do with the System.Security.Claims.Claim which has Type and Value. But it seems that if you add Resources of Address and Salary, and Operations of View and Edit there is no pairing.

So while I might give someone 1) Address/Edit, and Salary/View expecting them to not be able to edit Salary information it will let them.

What I’ve seen is it work this way: Look in all the Resources – do they have Salary? Good, now look in all the Operations – do they have Edit? Great, let them do it!

That’s not what I expected, wanted, and frankly I’ve not yet come up with a scenario where I think it would be useful.

ClaimAuthorize

So what I did instead was create a new attribute called ClaimAuthorizeAttribute.

So now if I have a ClaimIdentity with Claims of new Claim(“Address”, “Edit”) and new Claim(“Salary”, “View”) and place this on the action or controller:

[ClaimAuthorize(ClaimType=”Salary”, ClaimValue=”Edit”)]

The user would not get through.

So here is the code for that. If someone really wants it, I also have all the unit tests for it.

ClaimAuthorizeAttribute
  1. /// <summary>
  2. /// Specifies that access to a controller or action method is restricted
  3. /// to users who meet the claims requirement.
  4. /// </summary>
  5. [AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, Inherited = true, AllowMultiple = true)]
  6. public class ClaimAuthorizeAttribute : FilterAttribute, IAuthorizationFilter
  7. {
  8.     /// <summary>
  9.     /// Called when a process requests authorization.
  10.     /// </summary>
  11.     /// <param name="filterContext">The filter context, which encapsulates for information
  12.     /// using Ccr.Web.Mvc.ClaimAuthorizeAttribute.</param>
  13.     /// <exception cref="System.ArgumentNullException">The filterContext is null.</exception>
  14.     public void OnAuthorization(AuthorizationContext filterContext)
  15.     {
  16.         if (ReferenceEquals(filterContext, null))
  17.             throw new ArgumentNullException("filterContext");
  18.         if (!IsAuthorized(filterContext.HttpContext, ClaimType, ClaimValue))
  19.             HandleUnauthorizedRequest(filterContext);
  20.     }
  21.  
  22.     // Optional parameters to make unit testing easier.
  23.     internal static bool IsAuthorized(HttpContextBase httpContext, string claimType = "", string claimValue = "")
  24.     {
  25.         if (ReferenceEquals(httpContext, null))
  26.             throw new ArgumentNullException("httpContext");
  27.         var user = httpContext.User;
  28.         if (!user.Identity.IsAuthenticated)
  29.             return false;
  30.  
  31.         var claimsPrincipal = user as ClaimsPrincipal;
  32.         if (ReferenceEquals(claimsPrincipal, null))
  33.             return false;
  34.  
  35.         if (claimsPrincipal.HasClaim(claimType, claimValue))
  36.             return true;
  37.  
  38.         return false;
  39.     }
  40.  
  41.     /// <summary>
  42.     /// Gets or sets the claim type required for access to the controller or action.
  43.     /// </summary>
  44.     public string ClaimType { get; set; }
  45.  
  46.     /// <summary>
  47.     /// Optionally gets or sets the claim value required for access to the controller or action.
  48.     /// If not specified, then "True" will be used. The convention for most claims is that the
  49.     /// value is set to True.
  50.     /// </summary>
  51.  
  52.     private string _claimValue = true.ToString(CultureInfo.InvariantCulture);
  53.     public string ClaimValue
  54.     {
  55.         get { return _claimValue; }
  56.         set { _claimValue = value; }
  57.     }
  58.  
  59.     /// <summary>
  60.     /// Processes HTTP requests that fail authorization.
  61.     /// </summary>
  62.     /// <param name="filterContext">Encapsulates the information for using Ccr.Web.Mvc.ClaimAuthorizeAttribute.
  63.     /// The filterContext object contains the controller, HTTP context, reqest context,
  64.     /// action result, and route data.</param>
  65.     protected virtual void HandleUnauthorizedRequest(AuthorizationContext filterContext)
  66.     {
  67.         if (ReferenceEquals(filterContext, null))
  68.             throw new ArgumentNullException("filterContext");
  69.         filterContext.Result = new HttpUnauthorizedResult();
  70.     }
  71. }

If someone sees something I’m doing with the ClaimsPrincipalPermission attribute, please let me know.

Thanks – Karl

Posted

in

by

Karl

Tags:

,

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.