Security and roles authorization with model view presenter design pattern

Question

Where is the most fitting place for security and roles authorization to fit into the model view presenter design pattern?

Would it be for all pages that implement security to implement a specific interface, say IAuthorizedView that's along the lines of

public interface IAuthorizedView : IView
{
    IUser user;
    void AuthorizationInitialized();
    void AuthorizationInvoked();
}

Then handled inside the presenter level

public abstract class Presenter<TView> where TView : IView
{
    public TView View { get; set; }

    public virtual void OnViewInitialized()
    {
    }

    public virtual void OnViewLoaded()
    {
    }
}

public abstract class AuthorizationSecuredPresenter<TView> 
                        : Presenter<TView> where TView : IAuthorizedView 
{
    public override void OnViewInitialized()
    {
        View.AuthorizationInitialized();
        base.OnViewInitialized();
    }

    public override void OnViewLoaded()
    {
        View.AuthorizationInvoked();
        base.OnViewLoaded();
    }
}

This would be my first idea on it, the only question this would leave me is if we move from solely web based and added any type of API that required authorization on the service level that there would end up alot of duplication of access checking or is that perfectly acceptable to verify twice and should be designed for up front?

Answer 1

Here is something that you might want to consider.

I would use the decorator pattern to authorize each call to your object separatly.

Let's say you have the following class:

public class MyService
{
    public virtual void DoSomething()
    {
        //do something on the server
    }
}

You would then proceed to create a base decorator to implement the default constructor like this:

public class MyServiceDecoratorBase : MyService
{
    public MyServiceDecoratorBase(MyService service)
    {
    }
}

Once this is setup, you can actually start to decorate by creating an authorization decorator like this:

public class MyServiceAuthorizationDecorator : MyServiceDecoratorBase
{
    private readonly MyService _service;
    public MyServiceDecoratorBase(MyService service)
    {
        _service = service;
    }

    public override void DoSomething()
    {
        //TODO: Authorize the user here.
        _service.DoSomething();
    }
}

So now that the main classes are done... how are you going to call all this? Easy!

MyService service = new MyServiceAuthorizationDecorator(new MyService());
service.DoSomething();

Now... the advantage of all that is that your authorization logic is completely decoupled from your main service(or object) logic. Why is this important? Testability. You can test your main service independently of your authorization logic. This correspond to the Open/Close Principle.

Now, let's say you want to calculate performance on those pesky methods... add a decorator! Logging? Another decorator! They can all be chained that way. Of course, the more you add and the heavier it gets but I think that it's worth it for the advantage it gives.

Comments?