Search code examples
phpacluser-permissionsdatabase-permissions

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


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.


Solution

  • 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.