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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With