RBAC with additional level

Question

I am trying to design a database for RBAC with a twist (or perhaps its only me who thinks its a twist?). As I understand RBAC uses roles and permissions to grant/deny access to certain objects in my system. Everything is nice and clear when I have just one instance of my site and simply create a role 'Main admin', 'Secondary admin', 'User' etc.

However what if I have accounts inside the system? So I have one system which has say 'London', 'Tokyo' and 'Moscow' accounts. Now I will have 'Main admin' for each of the accounts, as well as many 'Users' in each account - of course Moscow guys should not be able to login to London account. How do I do it? Do I create some additional table that will bind assignments to accounts to users? Or do I add accountid to assignments table? Or perhaps i should create multiple roles like 'moscow_main_admin', 'london_main_admin' etc. What is the best approach for this type of situation?

Also I believe I will have some users who are 'Main admin' for London account and 'Secondary admin' for Tokyo account.

I plan to use Yii with it's built in RBAC... if that makes any difference.

How to tackle it?

Thank you in advance!

Answer 1

You could keep the "admin" roles and rules as you've already used them. And add a new role for each town 'moscow', 'london', etc.... In your controller, call a checkAccess in your action methods like 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 CController in your component directory, and overrides 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 of your question, there could be two ways to resolve your problems.

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

The second way is (if it may be of interest) is something that I've experimented with when attempting to "extend" RBAC for academic reasons.

What I have done is to allow the definition of two or more "named" levels to each Role. So given a Programmer role, my implementation allows for the addition of levels to a role, such as:

Programmer, level definition:

1. "Senior" = level 500
2. "Intermediate" = level 200
3. "Junior" = level 0

So when someone would assign permissions on an instance of an object such as a specification document, it could be assigned in the following way:

"Some document" -> Programmer (level 300) -> can edit "Some document" -> Programmer (level 0) -> can read "Some document" -> Programmer (level 500) -> can delete

This indicates that all Programmers can read the document but Juniors and Intermediates are not allowed to edit such document for lack of "level" authority. And only the Senior Programmer may delete the document.

This allows for me to have 3 distinct levels of permissions by only creating a single role. In a traditional system, I would have had to create the three distinct roles (4 with inheritance), such as:

In a non-hierarchical implementation:

1. Senior Programmer
2. Intermediate Programmer
3. Junior Programmer

In a hierarchical implementation:

1. Programmer
2. Senior Programmer (extends Programmer)
3. Intermediate Programmer (extends Programmer)
4. Junior Programmer (extends Programmer)

Obviously, levels need to be properly defined as sub-roles. Defining a level as "Analyst" would not be valid since these are two different roles and not a sub-type.

Answer 3

The best suitable for your requirement is to create a group and group hierarchy. Assign role to a group which will indirectly assign to all of its child groups. By that way you can assign common role to parent group and individual role to individual group. So, in your case London, Tokyo and Moscow are groups.

I implemented this solution via security access control tool Visual Guard, which has implemented and covered most of the application security concerns.

I have used Visual guard to access control for multi tenant and saas applications wherein I have used groups extensively.

Click here to read more.

Answer 4

A longstanding problem in RBAC. Adding context to the decision, e.g. account, causes an explosion of Roles. Here's an article, written by me, that describes the problem, and how role constraints can solve the problem.

https://iamfortress.net/2018/07/07/towards-an-attribute-based-role-based-access-control-system/