From my last post you can maybe tell that I prefer to keep my business and authorization logic separate. I am also not a huge fan of annotating my façade with role requirements like the [Authorize] attribute does.

In this post I described that deriving from AuthorizeAttribute is your entry point into a custom authorization system – and this is also exactly the technique I used to experiment with authorization that allows better separation of authorization details from the controller as well as being able to centralize the authorization policy.

For those who read my last post, this falls mainly into the “coarse grained” category, but will also give you some access to parameters.

Note: As mentioned earlier, authorization seems to be a very emotional topic. I am not saying that you should do exactly the same. I am just describing what I did – and I wouldn’t even call that “done” – just my current thinking. Feedback is always welcome.

So the first thing I did was to define an interface:

public interface IAuthorizationManager

{

    bool CheckAccess(HttpActionContext context);

}

This allows having various implementations of an authorization manager – either very low level, or at an higher abstraction level. This also allows writing adapters to existing authorization plumbing like the ClaimsAuthorizationManager.

Then I created an AuthorizeAttribute derived class that looks for a registered implementation of the above interface to pass the context to. Where and how exactly you register the implementation is up to you. You could e.g. use the HttpConfiguration class for that, pass in the implementation via the attribute – or the dependency resolver.

The simplified attribute would look like this:

public class ApiAuthorizeAttribute : AuthorizeAttribute

{

    protected override bool IsAuthorized(HttpActionContext context)

    {

        // load registered implementation

        var manager = GetAuthorizationManager()
          as IAuthorizationManager;

        return manager.CheckAccess(context);

    }

}

From there you could think of all kinds of abstractions that match your “style” of authorization. I have some concrete implementations that I will walk you through in upcoming posts. For those who want to have a look right now – here’s the current source code (all subject to change of course ;)).