如何简化这个角色和权限管理的设计？

Question

我正在开发一个web应用程序，它的用户具有多个角色，每个用户都可以根据用户的角色以及该角色对操作的权限级别执行多个操作。我想出了以下模式。

用户

+--------+-------------------+
| UserID | UserName          |
+--------+-------------------+
| 1      | Alice             |
+--------+-------------------+
| 2      | Bob               |
+--------+-------------------+
| 3      | Charlie           |
+--------+-------------------+
| 4      | David             |
+--------+-------------------+

角色

+--------+-----------------+
| RoleID | RoleName        |
+--------+-----------------+
| 1      | Tech_Admin      |
+--------+-----------------+
| 2      | Tech_Normal     |
+--------+-----------------+
| 3      | Non_Tech_Admin  |
+--------+-----------------+
| 4      | Non_Tech_Normal |
+--------+-----------------+

PermissionLevels

+-------------------+----------------------+
| PermissionLevelID | PermissionLevel      |
+-------------------+----------------------+
| 1                 | Tech_Account         |
+-------------------+----------------------+
| 2                 | Non_Tech_Own_Account |
+-------------------+----------------------+
| 3                 | Non_Tech_Any_Account |
+-------------------+----------------------+
| 4                 | Own_User             |
+-------------------+----------------------+

UserRoles

+--------+--------+
| UserID | RoleID |
+--------+--------+
| 1      | 1      |
+--------+--------+
| 2      | 2      |
+--------+--------+
| 3      | 3      |
+--------+--------+
| 4      | 4      |
+--------+--------+

命令

+-----------+--------------+
| CommandID | CommandName  |
+-----------+--------------+
| 1         | CREATE_USER  |
+-----------+--------------+
| 2         | EDIT_USER    |
+-----------+--------------+
| 3         | VIEW_USER    |
+-----------+--------------+
| 4         | EDIT_PROFILE |
+-----------+--------------+
| 5         | VIEW_PROFILE |
+-----------+--------------+
| 6         | SUSPEND_USER |
+-----------+--------------+

RoleCommands

+--------+-----------+-------------------+
| RoleID | CommandID | PermissionLevelID |
+--------+-----------+-------------------+
| 1      | 1         | 1                 |
+--------+-----------+-------------------+
| 1      | 1         | 3                 |
+--------+-----------+-------------------+
| 2      | 2         | 1                 |
+--------+-----------+-------------------+
| 3      | 2         | 2                 |
+--------+-----------+-------------------+
| 4      | 5         | 4                 |
+--------+-----------+-------------------+

为了简单起见，我没有描述帐户的细节，但每个用户都属于一个帐户- 'Tech‘或’非技术‘。系统中只有一个技术账户。

下面是按照RoleCommands表的业务规则示例。

• 技术管理员可以在技术帐户中创建用户。
• 技术管理员可以在任何非技术帐户中创建用户。
• 技术正常人可以编辑技术帐户中的用户。
• 非技术管理员可以在他们自己的非技术帐户中编辑用户。
• 非Tech可以查看自己的配置文件--这意味着其他用户无法查看该用户的配置文件。

当我收到新的REST请求时，我将根据请求参数标识操作，并验证用户是否拥有基于RoleCommands表执行操作的权限。这看起来像一个合理的角色和权限管理设计吗？

更新

看起来RoleCommands表中的记录太多了，因为对于每个命令，都会有几个角色和权限级别的组合。对于给定的对象，可以有n(例如: 10)状态，对象可以在其中。我希望向用户授予View_Object_Status1命令权限，以便当对象的状态为Status1时，用户可以查看它。这是在炸毁RoleCommands表。简化这个程序的最好方法是什么？

Answer 1

你目前的设计如下：

你应该问问自己：

• 实体PERMISSION_LEVEL是否代表实际级别？

如果它们是实际的级别，这意味着当用户被授予两个不同的角色，并且两个角色都有相同的命令，但是不同的级别时，应用程序应该占据其中的最高级别。在没有权限级别的角色权限模型中，使用set逻辑，因此，如果用户以相同的权限结束两次，那么这并不重要。重要的是权限存在于集合中，而不是存在多少次。但是您的模型有权限级别，所以当用户在不同的权限级别上不止一次地拥有相同的角色命令时，您应该决定要做什么。

另一方面，在更新您的问题时，您会提到一个新的实体，它没有显示在模型中，即对象。

• 物体在哪里落入模型中？

对于我所能看到的，模型将被更新如下：

这实际上会大大增加结果表的行数。但是，如果您创建了适当的索引和FK，那么这应该不会让您太担心。让我担心的是角色组装的复杂性，但至少应该只做一次。

我不确定我最后是否提出了更多的问题，我给出的答案。

Answer 2

这看起来像一个合理的角色和权限管理设计吗？

“合理”一词在这里有点含糊不清。

适合于用途

本设计达到了设计目的。它允许确定任何登录用户可以对任何特定业务对象执行哪些操作：

• 识别用户
• 角色被确定
• 用户被分配到角色。
• 命令被标识-显然是指业务对象上的操作(本例中的用户帐户)。
• 权限级别被标识-显然权限级别限制在命令中管理的业务对象。
• 具有权限级别的命令分配给角色。

强度

此设计允许基于日常角色的访问管理，正如现代业务应用程序所期望的那样。

这种设计是灵活的。它允许使用非常细的粒度定制角色，以便能够实现任何可能的访问配置(假设权限级别适当地代表了该事项中的分段需求)。

弱点

角色的建构需要所有组合的明确输入。如果命令或权限级别太细，这可能会很乏味。

权限级别在所有业务对象中都很常见：

• 如果您只管理几个业务对象，这些对象具有相似的访问规则，这是可以的。
• 如果对不同的业务对象需要不同的访问规则，则需要添加更多的权限级别，这可能会导致命令和权限级别之间的不一致。

顺便说一句，当前的权限级别列表并没有明确地涵盖整个数据集:我建议将"Tech_Own“重命名为"Tech_any”，将"Tech“重命名为”Tech_any“。我知道“任何”的意思是“除他自己的以外的任何”。

编辑：

按照您关于管理几个业务对象的意见，我建议您添加一个业务对象表，并更改命令表和权限级别，以便它们都与业务对象相关联。

这样，您将确保您的概要文件总是关联兼容的命令和权限级别:您只需在这个表中引入业务对象id即可。

这不会使角色变得更简单，但这不仅可以解决您的问题，而且还允许向角色管理器提供一个很好的用户界面，以方便输入(总是在兼容的元素之间进行选择)。

Answer 3

以下是我如何处理这一情况的方法：

1. 保留您的用户表
2. 你所认为的角色基本上是一群用户。因此，我们创建了一个新的表组
3. 您所称的PermissionLevel相当于组成员可以拥有的角色(例如。Tech_Admin的用户可以扮演Tech_Account和Non_Tech_account的角色。
4. 我将用一个名为Modules的表替换命令表，在该表中，它保留需要应用权限的不同区域(例如。(用户、个人资料、报告等)
5. 为了保留权限，我将使用CRUD (创建、读取、更新、删除)方法。虽然它可能是限制性的，但它经常用于权限设计。可以将CRUD值存储为检查位的字节或单独的列。

在这里，我们讨论了一个关于您的应用程序和设计的重要问题:什么定义了命令的权限？是角色、组或用户可以有单独的权限来覆盖组权限吗？

我们可以使用以下表格：

GroupPermissions

GPID - ModuleID - CRUD (或CRUD的单独列)

RolePermissions

RoleID - ModuleID - CRUD

下一个问题:在您的应用程序中，角色可以独立于组存在吗？如果是，上述表格就足够了。否则，您需要一个表来连接这两个

GroupsRoles

网格- GroupID - RoleID

下一个问题:用户是否可以仅仅是某个组的一部分，或者可以独立地扮演S/他所属的组的角色？

如果是前者，你需要这样的桌子吗？

GroupsUsers

GUID - UserID - GroupID

如果是后者，则需要多一个表。

RolesUsers

RUID - UserID - RoleID

最后，如果用户可以拥有单独的权限级别，而不管对组或角色的参与程度，则需要使用此表。

ModulesUsers

UserID - ModuleID - CRUD

根据有关权限传播的策略，您可以开始检查最后三个表，并决定允许用户做什么。