ACL modeling - how to manage “hierarchy” of an Access control list?

Question

I'm still working in my ACL project, and I'd like some ideas for the following problem:

I'm using MySQL to store my users, roles and permissions. At first, I created a field "parent_id" in my TABLE Roles, and I was trying to manage the permissions of each user through this. It was kind of working, till I realised that if I add a new role, it was really complicated to manage the hierarchy and control who has access to which resource. I did some searches and I realise it's really complicated to use a relational database to work with hierarchy, so I gave up using hierarchy.

I'd like your help to find the best solution to manage the creation of users: I have 4 different users: SuperAdmin, CustomerAdmin, Technician, client. When I'm in the page to create new users, I don't want to let a technician creates a new user of the type CustomerAdmin, or SuperAdmin, for example.

I thought in letting only the SuperAdmin create a new user, but one of my constraints is that I must let a CustomerAdmin create users too, also a technician.

Trying to be more didactic, the SuperAdmin can be me. The customer admin is my client and he has an enterprise. In his enterprise, he can create 2 types of users: technicians and clients.

This is just an example, but if I want to create a new kind of role giving him new permissions, I must find a way to deny him the permission to create a more powerful user than him.

I'm not sure if I was objective in my question, but anyone who can talk about this with me will be welcome.

Answer 1

You already have your roles but each role needs to have rights to perform actions. This is almost certainly overkill but it should be highly flexible.

 | Role Table                           | 
 | Role ID | Role Name   | Access Level |
 ----------------------------------------
 |       1 | SuperAdmin  |           10 |
 |       2 | ClientAdmin |           20 |
 |       3 | Technician  |           40 |
 |       4 | Client      |           80 |

 | Action Table            |
 | Action ID | Action Name |
 ---------------------------
 |         1 | Create User |
 |         2 | Delete User |
 Etc.

 | Rights Table                   |
 | Right ID | Role ID | Action ID |
 ----------------------------------
 |        1 |       1 |         1 |
 |        2 |       1 |         2 |
 |        3 |       2 |         1 |
 |        4 |       2 |         2 |
 Etc.

 | Parameter Table                                         |
 | Param ID | Right ID | Parameter Name  | Parameter Value |
 -----------------------------------------------------------
 |        1 |        1 | Max User Access |              10 |
 |        2 |        2 | Max User Access |              10 |
 |        3 |        3 | Max User Access |              20 |
 |        4 |        4 | Max User Access |              20 |
 Etc.

The Rights table shows that both SuperAdmin and ClientAdmin can create and delete users. The Parameter table restricts ClientAdmin to creating users with a maximum access level of 20 (1 being the highest). You can match this access level back to a role to offer a list of roles for the new user where Role.Access_Level >= Max User Access.

Actions can use more than one parameter set according to right but I couldn't think of anything other than Max User Access.

Answer 2

What if you used a permission value-type scheme where a number represents the permission "level" and at certain increments you get certain permissions?

E.G.

Super admin 10000 Customer admin 1000 Technician 100 Peon 10

Can read = 10 Can write settings = 100 Can create users 1000

If the target user of an action has a higher permission number than the user performing the action, deny the action. That's a fairly simple way to abstract what those mean without building a materialized path and having to build a tree datastructure.