Resource/Action based Authorization for OWIN (and MVC and Web API)

Authorization is hard – much harder than authentication because it is so application specific. Microsoft went through several iterations of authorization plumbing in .NET, e.g. PrincipalPermission, IsInRole, Authorization configuration element and AuthorizeAttribute. All of the above are horrible approaches and bad style since they encourage you to mix business and authorization logic (aka role names inside your business code).

WIF’s ClaimsPrincipalPermission and ClaimsAuthorizationManager tried to provide better separation of concerns – while this was a step in the right direction, the implementation was “sub-optimal” – based on a CLR permission attribute, exception based, no async, bad for unit testing etc…

In the past Brock and me worked on more modern versions that integrate nicer with frameworks like Web API and MVC, but with the advent of OWIN/Katana there was a chance to start over…

Resource Authorization Manager & Context
We are mimicking the WIF resource/action based authorization approach – which proved to be general enough to build your own logic on top. We removed the dependency on System.IdentityModel and made the interface async (since you probably will need to do I/O at some point). This is the place where you will centralize your authorization policy:

public interface IResourceAuthorizationManager


    Task<bool> CheckAccessAsync(ResourceAuthorizationContext context);



(there is also a ResourceAuthorizationManager base class with some easy to use helpers for returning true/false and evaluations)

The context allows you to describe the actions and resources as lists of claims:

public class ResourceAuthorizationContext
    public IEnumerable<Claim> Action { get; set; }
    public IEnumerable<Claim> Resource { get; set; }
    public ClaimsPrincipal Principal { get; set; }


The corresponding middleware makes the authorization manager available in the OWIN enviroment:

public void Configuration(IAppBuilder app)
    var cookie = new CookieAuthenticationOptions
        AuthenticationType = "Cookie",
        ExpireTimeSpan = TimeSpan.FromMinutes(20),
        LoginPath = new PathString("/Login"),
    app.UseResourceAuthorization(new ChinookAuthorization());


Since the authorization manager is now available from the environment (key: idm:resourceAuthorizationManager) you can get ahold of it from anywhere in the pipeline, construct the context and call the CheckAccessAsync method.

The Web API and MVC integration packages provide a ResourceAuthorize attribute for declarative checks:

[ResourceAuthorize(ChinookResources.AlbumActions.View, ChinookResources.Album)]


And several extension methods for HttpContextBase and HttpRequestMessage, e.g.:

if (!HttpContext.CheckAccess(
    return new HttpUnauthorizedResult();



var result = Request.CheckAccess(


Testing authorization policy
Separating authorization policy from controllers and business logic is a good thing, centralizing the policy into a single place also has the nice benefit that you can now write unit tests against your authorization rules, e.g.:

public void Authenticated_Admin_Can_Edit_Album()
    var ctx = new ResourceAuthorizationContext(User("test", "Admin"),



public void Authenticated_Manager_Cannot_Edit_Track()
    var ctx = new ResourceAuthorizationContext(User("test", "Manager"),


Code, Samples, Nuget
The authorization manager, context, middleware and integration packages are part of Thinktecture.IdentityModel – see here.

The corresponding Nuget packages are:

..and here’s a sample using MVC (if anyone wants to add a Web API to it – send me a PR).

This entry was posted in ASP.NET, IdentityModel, Katana, OWIN, WebAPI. Bookmark the permalink.

23 Responses to Resource/Action based Authorization for OWIN (and MVC and Web API)

  1. larry says:

    I downloaded the ResourceAuthorizationSample and am seeing a problem with the Claim.Properties property.

    If I edit the InMemoryClaimsRepository’s GetClaimsForUser method and add a test key-value pair onto the Claim.Properties property, it is not there when I later check for it in the ChinookAuthorization’s CheckAccessAsync override method. The Claim is there but the Properties property is empty.

    Is there anything special I need to do to have the Claims.Property “persist” in the Claim?

  2. Raf says:

    1) So this is your recommended way to perform granular authorization?

    I’m still new to the IdentityServer.3 approach but I certainly will use it on the application I’m working on. And I am trying to understand what is the best possible way to perform granular authorization.

    My app has tons of actions/resources so I will need to store this inside a database so Im guessing I will have to implement my own version of ResourceAuthorizationManager.

    2) If I were to use this approach with IdentityServer.3 that means I will have to use the claims (or scopes?) returned on the token instead of having my own ClaimRepository implementation. Right?

  3. Khaled Hammouda says:

    How do I combine resource authorization with OAuth bearer token authentication?

    Previously I had this in my OWIN configuration:

    app.UseOAuthBearerAuthentication( new OAuthBearerAuthenticationOptions {} );

    And my controller:

    public class IssuesController : ApiController {


    The [Authorize] attribute caused the OAuth token validation to be enforced, so this part was fine.

    Now I have:

    app.UseOAuthBearerAuthentication( new OAuthBearerAuthenticationOptions {} );
    app.UseResourceAuthorization( new MyAuthorizationManager() );

    [ResourceAuthorize( “Access”, “Things” )]
    public class IssuesController : ApiController {


    But now the OAuth token validation doesn’t work. If I add the [Authorize] attribute to the controller it works. So is this how it’s supposed to be:

    [ResourceAuthorize( “Access”, “Things” )]
    public class IssuesController : ApiController {


    Seems a bit redundant to me to require to authorization attributes to have this work, because from your example you seem to be able to achieve both resource authorization and cookie authentication by just using the ResourceAuthorizeAttribute.

  4. Pingback: Common authentication/authorization between .NET4.0 and .NET4.5 web applications | Low Level Design

  5. Vassago says:


    Hopefully this is a simple yes/no question. I’ll admit that I haven’t downloaded your sample projects yet, so please excuse any ignorance displayed :)

    I have a requirement to be able to authorise a user’s access to individual the properties and methods of a particular /instance/ of an object they are accessing… i.e. not just the /type/ of object they are accessing. My specific scenario is that Users can have a maximum of one type of relationship with an Account. E.g. they could be the “AccountHolder” of the Account, the “AccountOpertor”, the “AccountViewer”, etc. They could also have different relationships to different Accounts and these relationship types could change over time.

    Whenever a user selects an account, I need to work out whether or not to display the Balance to them. In other words, I would need to know whether the current user has permission to access the Balance property of the particular Account object that I have just fetched. This will depend on their type of relationship with that Account.

    I have been able to do such “instance level” authorisation in the past using the CSLA business framework, but this has fallen out of favour in my company as we’ve moved towards MVC, IOC etc. (but that’s another argument ;). Anyway, whilst looking into alternative frameworks, I’ve struggled to find one that would support the scenario I described above so I was wondering if you could give me a quick answer: Can the IdentityServer.3 framework support instance level authorisation?


    P.S. In case it matters, this will be a .NET 4.5 project deployed on Windows Server 2012 using ASP.NET MVC 5 for the web front end and Entity Framework 6 for data access to a SQL Server back-end. Not decided on a “middle tier” business framework yet.

    • The simple answer is no – IdentityServer3 is a token service, not an authorization framework.

      For the long answer – check out the sample projects ;)

    • Take a look at the VITA authorization framework:

      I haven’t used it personally, and it looks like a swiss army knife, so I can’t endorse it. I’m just sharing a resource that seems to do what you want, and possibly provide you with insight into how to do it if you were to do it on your own.

      • Vassago says:

        Thanks Khaled, that looks really interesting. I especially like the split between ‘peek’ and ‘read’… Can’t believe I never thought of that myself!… and also the idea of granting access with a using statement only for a specific purpose.

        Not sure how well the ‘SecureSession’ will play with our IOC framework but I can certainly see us using some of its ideas if not the whole framework.

        Thanks again

  6. I can’t find any documentation for using ResourceAuthorize in Asp.Net 5. Which is shocking, considering that Asp.Net 5 has been in RTW for a full day already ;-)
    Do you have any plans to support Asp.Net 5 (MVC6)? If you already do, could you please point me to some documentation on how to set this up?

    • AspNet5 is still beta. They are working on a similar feature for authZ themselves. No idea what the status is. We have no plans currently to port our stuff.

      • You are right, it is still beta. I saw the announcement on the start page of Visual Studio and didn’t bother reading the entire article…
        Is there anything public on for Microsoft’s authZ effort? I didn’t find anything relevant by googling.

  7. Saw it on github (security repo)

  8. percollin says:

    Why does the ResourceAuthorizeAttribute in Thinktecture.IdentityModel,Mvc wait by default for 5000 ms before throwing a timeout exception in the CheckAccess method:

    protected virtual bool CheckAccess(HttpContextBase httpContext, string action, params string[] resources)
    Task task = HttpContextExtensions.CheckAccessAsync(httpContext, action, resources);
    if (task.Wait(5000))
    return task.Result;
    throw new TimeoutException();

    Is there anyway to go around this? What if I want to debug my ResourceAuthorizationManager?

  9. Well – we essentially need to call async code from sync code. We need a timeout.

  10. Matt says:

    Can I ask a question about MVC views. I understand how to setup a ‘ResourceAuthorize’ attribute on a controller action. I’m pulling down the claims and transforming them so they’re available to the User object in an MVC view.

    Is it possible to use the ResourceAuthorize attribute inside a view? I currently have to use roles directly in the views (e.g. @if (User.IsInRole(“CanAccessSite”)).

    • You can use the programmatic approach. But it would be better style if your view model would contain all relevant information and view would just do the rendering based on that.

  11. Matt says:

    Thanks. That makes sense. I was interrogating roles in the Layout so will have to re-design a little. But putting them in the ViewModel appears the neater solution anyway.

  12. How do I implement this if I had the access permissions stored in a database?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s