ACL建模 - 如何管理Access控制列表的“层次结构”?

时间:2021-09-11 16:53:50

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

我还在我的ACL项目中工作,我想了解以下问题的一些想法:

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.

我正在使用MySQL来存储我的用户,角色和权限。首先,我在TABLE Roles中创建了一个字段“parent_id”,我试图通过它来管理每个用户的权限。它有点工作,直到我意识到,如果我添加一个新角色,管理层次结构和控制谁有权访问哪些资源真的很复杂。我做了一些搜索,我发现使用关系数据库来处理层次结构非常复杂,所以我放弃了使用层次结构。

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.

我希望您帮助找到管理用户创建的最佳解决方案:我有4个不同的用户:SuperAdmin,CustomerAdmin,Technician,client。当我在页面中创建新用户时,我不想让技术人员创建一个CustomerAdmin类型的新用户,例如SuperAdmin。

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.

我想只让SuperAdmin创建一个新用户,但我的一个限制是我必须让CustomerAdmin也创建用户,也是技术人员。

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.

为了更加说教,SuperAdmin可以成为我。客户管理员是我的客户,他有一个企业。在他的企业中,他可以创建两种类型的用户:技术人员和客户。

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.

我不确定我的问题是否客观,但任何能与我谈论此事的人都会受到欢迎。

2 个解决方案

#1


4  

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.

权限表显示SuperAdmin和ClientAdmin都可以创建和删除用户。 Parameter表限制ClientAdmin创建最大访问级别为20(1为最高)的用户。您可以将此访问级别与角色匹配,以便为Role.Access_Level> =最大用户访问权限的新用户提供角色列表。

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

动作可以根据权利使用多个参数集,但除了Max User Access之外我无法想到任何其他参数。

#2


1  

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

超级管理员10000客户管理员1000技师100 Peon 10

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

可以读取= 10可以写入设置= 100可以创建用户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.

如果操作的目标用户具有比执行操作的用户更高的权限编号,则拒绝该操作。这是一种相当简单的方法,可以在不构建物化路径和必须构建树数据结构的情况下抽象那些意味着什么。

#1


4  

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.

权限表显示SuperAdmin和ClientAdmin都可以创建和删除用户。 Parameter表限制ClientAdmin创建最大访问级别为20(1为最高)的用户。您可以将此访问级别与角色匹配,以便为Role.Access_Level> =最大用户访问权限的新用户提供角色列表。

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

动作可以根据权利使用多个参数集,但除了Max User Access之外我无法想到任何其他参数。

#2


1  

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

超级管理员10000客户管理员1000技师100 Peon 10

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

可以读取= 10可以写入设置= 100可以创建用户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.

如果操作的目标用户具有比执行操作的用户更高的权限编号,则拒绝该操作。这是一种相当简单的方法,可以在不构建物化路径和必须构建树数据结构的情况下抽象那些意味着什么。