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: Non RBAC User Roles and Permissions System: checking the user's 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.
Let me first say that both of your questions are basically the same and should be consolidated . There is no value in multiple variations of the same concept.
You wish to add an extra level of arbitrary discrimination to the basic role.
To implement this sort of RBAC and retain the ability to take advantage of any of the inbuilt infrastructure you will need to make a few compromises and build a few custom implementations.
The first step is the compromise of adopting a role definition convention. e.g. when you want to determine if a user is in role 'manager' of 'companyA' you would define the rule, be it an attribute, code or perhaps a sitemaps, as 'manager-companyA' i.e. IsUserInRole("manager-companyA").
The second step is a custom RoleProvider implementation that can parse this and appropriately query your underlying data source maintaining the hierarchial relationships, for which you will have to provide a custom UI for maintenance.
You will need to, at a minimum, implement the methods used by ASP.Net to ensure that the roles are checked or output in the correct format.
IsUserInRole will get a string that you will have to, using convention, parse into constituent segments for verification, as described previously.
GetRolesForUser can be called when caching roles in cookies and must perform a hierarchial recursion of the roles and output all permutations. e.g. A user is manager for companyA and companyB so GetRolesForUser("user") should return an array consisting of the values manager-companyA and manager-companyB for use by the asp.net infrastructure that utilizes cached roles and does not interactively poll the RoleProvider.
This type of approach will provide you with the widest availability of established ASP.Net RBAC facilities while providing you with the customization you require.
So, to conclude, whenever you can adjust your expectations and/or redefine your requirements to work as much as possible with the existing infrastructure the less (MUCH LESS) code you must actually design, implement, test and maintain and the more time you have to spend concentrating on other aspects of your systems that do not already have an established infrastructure in place.
I'm currently struggling myself trying to implement my own version of an RBAC library (for the simple reasons of learning the guts of RBAC all the while having it tunes specifically for my codebase/database). (Note: Constraints are the hard part)!!
The way I have dealt with that (yet to be fully implemented) is that I created Groups, which basically are a collection of Users. So in this case, I would create three groups; Company A, Company B and Company C and then assign each user appropriately to such groups (companies).
You can then assign the Manager role to specific users and the Groups can also be assigned Roles. I like this because it allows me to add a single roll to many users at once (very, very fast during DB transactions and once cached the memory footprint is much smaller).
So in your example, let's say you have an Institution model (or object instance) that is shown in your UI. By simply clicking on it and then selecting the 'Security' menu for it, you get a window for which allows you to add user/group members (like Windowns security). By adding (group) Company A and allowing 'read' permissions, you are in essence allowing all users within that group read access to that company and its child object which would be client contacts and thousands of other model instances.
It's probably not perfect, but it's the best solution that I have found thus far (although I still have questions myself for which I'm about to ask a question on SO).
If you're problem would be solved by implementing inheritance for roles you could implement that.
Your example is another opportunity to go the attribute based access control way (eg allow a user that has the role of manager AND works for Company A). It is much harder to implement that a RBAC system though.
I'm not sure whether this might be what you are looking for or not but in my own search for information on RBAC systems I think I may have found something that suits your needs. I was reading an article by Tony Marston he talks about Virtual Private Database/ Row Level Security. These would give permissions at the data level meaning that you could restrict users to certain subsets of the information in your database. The links to the article is below.
http://www.tonymarston.net/php-mysql/role-based-access-control.html (Look in the "Other Types Of Access Control" section at the bottom of the page)
Again, I am not sure this is what you are looking for or not but it might be worth a quick browse.
