RBAC with an additional layer

Question

I am trying to create a database for RBAC using a twist (or maybe just mine, who thinks about this?). As I understand it, RBAC uses roles and permissions to grant / deny access to certain objects on my system. Everything is fine and understandable when I have only one instance of my site and just create the roles " Main admin ", " Secondary admin ", " User ", etc.

However, what if I have accounts inside the system? So I have one system that says " London ", " Tokyo " and " Moscow ". Now I will have a "Chief Administrator" for each of the accounts, as well as for many "Users" on each account - of course, the Moscow guys will not be able to log into the London account. How should I do it? Create some additional table that will bind assignments to user accounts? Or can I add an account to the assignment table? Or maybe I should create some roles like "moscow_main_admin", "london_main_admin", etc. What is the best approach for this type of situation?

I also think that I will have some users who are the “Primary Administrator” for the London account and the “Secondary Administrator” for the Tokyo account.

I plan on using Yii with its built-in RBAC ... if that matters.

How to handle this?

Thank you in advance!

Answer 1

You can save admin roles and rules as you already used them. And add a new role for each city: Moscow, London, etc. In your controller, call checkAccess in your action methods, as in the following example.

 public function actionEditArticle($town) { if(!Yii::app()->user->checkAccess($town) Yii::app()->end(); // ... more code } 

A more advanced method would be to extend the CController in your component directory and override the runAction($action) method.

 public function runAction($action) { if (isset($_GET['town']) { if(!Yii::app()->user->checkAccess($_GET['town']) Yii::app()->end(); } parent::runAction($action); } 

Answer 2

From what I understand about your question, there can be two ways to solve your problems.

The first is the use of hierarchical roles (role inheritance). Although it is more difficult to implement and manage, it can provide a level of flexibility that is very interesting.

The second way (if that might be interesting) is that I experimented with trying to "expand" RBAC for academic reasons.

I did to allow the definition of two or more "named" levels of each role. Therefore, given the role of Programmer, my implementation allows me to add levels to the role, for example:

Programmer Level Definition:

• Senior = level 500
• Intermediate = Level 200
• "Junior" = level 0

So, when someone assigns permissions to an instance of an object, such as a specification document, it can be assigned as follows:

“Some documents” → Programmer (level 300) → can edit “Some documents” → Programmer (level 0) → can read “Some documents” → Programmer (level 500) → can delete

This indicates that all programmers can read the document, but juniors and intermediaries are not allowed to edit such a document due to the lack of “level” authority. And only a senior programmer can delete a document.

This allows me to have 3 different permission levels, creating only one role. In a traditional system, I would have to create three different roles (4 with inheritance), for example:

In non-hierarchical implementation:

• Senior programmer
• Intermediate programmer
• junior programmer

In a hierarchical implementation:

• Programmer
• Senior programmer (extends the program)
• Intermediate programmer (extends the program)
• Junior programmer (extends the program)

Obviously, levels must be correctly defined as sub-roles. The definition of Analyst is invalid because these are two different roles, not a subtype.

Answer 3

The most suitable for your requirement is to create a hierarchy of groups and groups. Assign a role to a group that indirectly assigns to all its child groups. Thus, you can assign a common role to a parent group and a separate role for a separate group. So, in your case, London, Tokyo and Moscow are groups.

I implemented this solution using the Visual Guard security access control tool, which implemented and covered most of the application security issues.

I used Visual guard to control access for applications with several tenants and Sámi, in which I actively used groups.

Click here to learn more.