Which Design Pattern to use for assigning allowed operations to user types?

Question

I'm developing a system in C# (.NET 4.0) which will be used by various kind of users.

Each user type will only be allowed to interact with the application in a specific way. For example, user A should only be able to do operations 1, 2 and 3. User B should only be able to do operation 2, 3 and 4. Etc.

I decided to implement an interface called "Role", which is implemented by various classes such as "Administrator", "Reader", etc. A user may have multiple roles (defined as a list of "Roles").

I'd like each role ("Administrator", "Reader", etc.) to have a list of allowed operations. I was thinking of defining an enum somewhere which will contain all operations possible within the application. Each "Role" would then have a list of items found in that enum.

I find this rather unoptimized, since I will have to always make sure to keep this enum up-to-date as I implement new functionalities in my application.

What approach would you recommend that I use ? Are there any design patterns that can help me out ?

Answer 1

I like this question, it's a good one. Whenever I come across problems like this, I always start to think about interfaces, actions and how they work together. Usually a factory or two suddenly decides that its presence needs to be felt in the final solution. So let's take a look at some interfaces that your problem consists of.

First up, we have a role. A role can be anything and is entirely business-specific as your question states. So, the role can actually be quite simple:

public interface IRole
{
    public string Name { get; }
}

(As you can probably tell, I am keeping this very simple). That's all a role is, really. A title. You might think it overkill just to have an interface that has a name parameter, but roles might well get more complex in at a later point.

Ok, we've defined an abstract concept of a role. I guess we're going to have some kind of a User class that is given a bunch of roles. Here's a simple one:

public class User
{
    private List<IRole> roles_ = new List<IRole>();

    /* .. usual suspects */

    public void AddRole(IRole role)
    {
        Debug.Assert(role != null);
        Debug.Assert(!HasRole(role));
        roles_.Add(role);
    }

    public void RevokeRole(IRole role)
    {
        Debug.Assert(role != null);
        roles_.Remove(role);
    }

    public bool HasRole(IRole role)
    {
         Debug.Assert(role);
         return roles_.Contains(role);
    }


    public bool CanPerform(IAction action)  /* to come */ 
}  // eo class User

Right now, we have a definition of a role, a concrete User class and the ability to add and revoke roles to a particular user. Time to define some concrete roles:

public class AdminRole : IRole
{
    public string Name { get { return "Admin"; } }
}

public class ReaderRole : IRole
{
    public string Name { get { return "Reader"; } }
}

The only thing we're really missing, is actions that can be performed. So, let's define a new interface:

public interface IAction
{
    string Name { get; }
    void Perform();
}

That's about as simple as it gets for an action. We'll make a dummy one:

public class InvoiceAction : IAction
{
     public string Name { get { return "Invoicing"; } }
     public void Perform()
     {
         /* Invoice somebody! */
     }

     public InvoiceAction(/* Some pertinent details*) { }
}

Right, we've got our basic interfaces and concrete classes in place. We now need to come up with a way that actions can be associated with roles. For the purposes of this example, I'm going to go with a RoleValidation class. You can probably think of a better name than this.

public sealed class RoleValidation
{
    private Dictionary<System.Type, List<IAction>> roleMap_ = new Dictionary<System.Type, List<IAction>>(); // this is our mapping of roles to actions

    // ctor ignored for brevity

    public void AssignActionToRole<ROLE>(IAction action)
    {
        Debug.Assert(action != null);
        if(roleMap_.ContainsKey(typeof(ROLE)))
            roleMap_[typeof(ROLE)].Add(action);
        else
        {
            List<IAction> actions = new List<IAction>();
            actions.Add(action);
            roleMap_[typeof(ROLE)] = actions;
        }
    }

    // Nice generic function for ease of use
    public List<IAction> GetActions<ROLE>() where ROLE : IRole
    {
        foreach(KeyValuePair<System.Type, IAction> pair in roleMap_)
        {
            if(typeof(ROLE).IsAssignableFrom(pair.Key.GetType()))
                return pair.Value;
        }
        return null;
    }

    // for everyone else, non-explicit
    public List<IAction> GetActions(System.Type type)
    {
        foreach(KeyValuePair<System.Type, IAction> pair in roleMap_)
        {
            if(type.IsAssignableFrom(pair.Key.GetType()))
                return pair.Value;
        }
        return null;
    }
} // eo class RoleValidation

Ok, what does this allow us to do? It allows us to use our RoleValidation class to associate actions with roles....

RoleValidation rv = new RoleValidation();
rv.AssignActionToRole<Administrator>(new InvoiceAction());
rv.AssignActionToRole<Reader>(new OtherAction());

I realise that there could be duplication of actions, and that is left as an exercise for the reader, as you could potentially create an action factory and use two generics here instead, e.g:

cv.AssignActionToRole<Administrator, InvoiceAction>();

And basically have a map of types, rather than concrete instances. That would be my preferred way of doing things.

Now it's type to implement that CanPerform function in our user class:

public class User
{
    /* you know the rest */
    public bool CanPerform(IAction action)
    {
        /* code assumes RoleValidation is available via some method or whatever */
        foreach(IRole role in roles_)
        {
            if(RoleValidation.Instance.GetActions(typeof(role)).Contains(action))
                return true;
        }
        return false;
    }
}

I admit, I have thrown this answer together without actually compiling it and constructing a working example, so I apologise if there are errors. This is one approach you could take to solving this and having dynamic actions, assigned to arbitrary roles and users with multiple roles. It could get more interesting if we consider roles might derive from one another, but that's a different story :)

Answer 2

Have a look at the Proxy Pattern. That should give you pointers at how to approach this scenario: http://en.wikipedia.org/wiki/Proxy_pattern

A protective proxy controls access to a sensitive master object. The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request.

http://sourcemaking.com/design_patterns/proxy