We are currently designing a User Roles and Permissions System in our web application (ASP.NET), and it seems that we have several cases that do no fit within the classical Role-Based Access Control (RBAC). I will post several questions, each devoted to a particular case. This is my second question (the first question is here: http://stackoverflow.com/questions/2839797/non-rbac-user-roles-and-permissions-system-checking-the-users-city).
We have the following case: we need to implement a Manager role in our web application. However, a Manager can belong to one or several companies (within a big group of companies for which we are creating this web app). Say, there can be “Manager of companies A and B”, “Manager of company C”, etc.
Depending on the companies that the Manager belongs, he has access to certain operations: for example, he can communicate with clients only of those companies that he belongs to. That is, “Manager of companies A and B” can only have contacts with clients of companies A and B, and not with those of company C. He can also view clients’ details pages of companies A and B and not of C, etc.
It seems that this case falls within the RBAC. However, this is not really the case. We will need to create a ManagerRole class that will have a Companies property – that is, this will not be just a role as a collection of permissions (like in the classical RBAC), but a role with properties!
This was just one example of a role having properties. There will be others: for example, an Administrator role that will also belong to a number of companies and will also have other custom properties.
This means that we will a hierarchy or roles classes:
class Role – base class
class ManagerRole : Role
List Companies
class AdministratorRole : Role
List Companies
Other properties
We investigated pure RBAC and its implementation in several systems, and found no systems featuring a hierarchy or roles, each having custom properties. In RBAC, roles are just collections of permissions.
We could model our cases using permission with properties, like ManagerPermission, AdministratorPermission, but this has a lot of drawbacks, the main being that we will not be able to assign a role like “Manager of Companies A and B” to a user directly, but will have to create a role containing a ManagerPermission for companies A and B… Moreover, a "Manager" seems to be rather a "role" (position in the company) rather than a "permission" from the linguistic point of view.
Would be grateful for any ideas on this subject, as well as any experience in this field!
Thank you.
