Non RBAC User Roles and Permissions System: Role with Properties

We are currently designing a system of user roles and permissions in our web application (ASP.NET), and it seems that we have several cases that are not suitable in classical role-based access control (RBAC) . I will post a few questions, each of which is dedicated to a specific case. This is my second question (first question here: Non RBAC User Roles and Permissions System: checking the user's city ).

We have the following case: we need to implement the Manager role in our web application. However, the manager may belong to one or several companies (in a large group of companies for which we create this web application). Say there may be a “Manager of Companies A and B,” “Manager of Company C,” etc.

Depending on the companies to which the Manager belongs, he has access to certain operations: for example, he can communicate with clients of only those companies to which he belongs. That is, the "Manager of companies A and B" can only have contacts with customers of companies A and B, and not with companies C. He can also view the pages of customers of companies A and B, not C, etc.

This case seems to fall into RBAC. However, this is actually not the case. We will need to create a ManagerRole class that will have the Companies property. This means that it will be not just the role of the permission set (as in the classic RBAC), but the role with the properties !

This was just one example of a role with properties. There will be others: for example, the administrator role , which will also belong to several companies, as well as other custom properties.

This means that we will use hierarchy or role classes:

class Rolebase class class ManagerRole : Role List Companies class AdministratorRole : Role List Companies Other properties 

We investigated pure RBAC and its implementation on several systems, and did not find systems with hierarchies or roles , each of which has user-defined properties. In RBAC, roles are simply collections of permissions.

We could model our cases using permissions with properties such as ManagerPermission, AdministratorPermission, but this has many drawbacks, the main one being that we will not be able to assign such a role as the “Manager of Company A and B” to the user directly, but he will have to create a role containing ManagerPermission for companies A and B ... Moreover, the “Manager” is likely to be a “role” (position in the company), rather than a “permission” from a linguistic point of view.

I would be grateful for any ideas on this issue, as well as for any experience in this area!

Thanks.

+4
source share
4 answers

Let me first say that both of your questions are basically the same and should be consolidated. In different versions of the same concept there is no meaning.

You want to add an extra layer of arbitrary discrimination to the main role.

In order to implement this type of RBAC and to retain the ability to use any built-in infrastructure, you will need to make several compromises and create several custom implementations.

The first step is to compromise the adoption of a role definition convention. for example, when you want to determine whether a user is in the role of "manager" in "companyA", you must define the rule, whether it is an attribute, code, or possibly Sitemap files, like "manager-companyA" ie IsUserInRole("manager-companyA")

The second step is a special implementation of RoleProvider, which can analyze this and query your underlying data source accordingly, maintaining hierarchical relationships for which you will need to provide a user interface for maintenance.

At a minimum, you need to implement the methods used by ASP.Net to ensure that roles are validated or displayed in the correct format.

IsUserInRole will receive a string that you need, using the convention, to parse into multiple segments for validation, as described earlier.

GetRolesForUser can be called when caching roles in cookies and perform hierarchical recursion of roles and display all permutations. for example, the User is the manager for companyA and companyB, so GetRolesForUser("user") must return an array of manager-companyA and manager-companyB for use by the asp.net infrastructure, which uses cached roles and does not conduct interactive polling of RoleProvider.

This type of approach will give you the widest availability of installed ASP.Net RBAC features, giving you the customization you need.

So in conclusion, whenever you can adjust your expectations and / or redefine your requirements in order to work as much as possible with the existing infrastructure, the less (MUCH LESS) code, you must actually design, implement, verify and maintain more time you need to spend focusing on other aspects of your systems that do not yet have an installed infrastructure.

+1
source

I'm currently struggling to implement my own version of the RBAC library (for simple reasons, to study the guts of RBAC all the time when it is configured specifically for my code / database database). (Note. Limitations are the hard part.)

The way I dealt with this (not yet fully implemented) is that I created groups, which are basically a collection of users. Therefore, in this case, I would create three groups; Company A, Company B, and Company C, and then assign each user to the appropriate groups (companies).

You can then assign the Manager role to specific users, and groups can also be assigned roles. I like this because it allows me to add one roll for many users at once (very, very fast during database transactions and after caching, the memory size is much less).

So, in your example, let's say you have an Instinct model (or an instance of an object) that is shown in your user interface. Just by clicking on it and then selecting the "Security" menu for it, you will get a window for which you can add users / group members (for example, Windowns security). By adding (group) company A and allowing “read” permissions, you, in essence, allow all users of this group to read access to this company and its child object, which will be the client’s contact and thousands of other model instances.

This is probably not ideal, but it is the best solution I have found so far (although I still have questions for which I am going to ask a question about SO).

+1
source

If the problem is resolved by implementing inheritance for roles, you can implement this.

Your example is another opportunity to switch to the access control path based on an attribute (for example, to allow a user who has the role of an AND manager to work in company A). However, it is much more difficult to implement the RBAC system.

0
source

I'm not sure if this might be what you are looking for or not, but in my own search for information on RBAC systems. I think I have found something that suits your needs. I read an article by Tony Marston in which he talks about the security of a virtual private database / row level. This will give permissions at the data level, which means that you can restrict users to certain subsets of the information in your database. Links to the article below.

http://www.tonymarston.net/php-mysql/role-based-access-control.html (see the "Other types of access control" section at the bottom of the page)

Again, I'm not sure if this is what you are looking for or not, but it may be worth a quick look.

0
source

Source: https://habr.com/ru/post/1309853/


All Articles