如何设计基于层次角色的访问控制系统 [英] How to design a hierarchical role based access control system

问题描述

最基本的是，我们为我们的项目定制了一个"kickstart".为此，我们正在考虑重做用户控件.我知道关于通用rbac的问题很多，但是在分层rbac上找不到任何问题吗?

Basic deal is, we have a custom built "kickstart" for our projects. For this we are looking at redoing the user control. I know there are a lot of questions out there about general rbac, but I cannot find any on hierarchical rbac?

我们的要求是:

• 可以将角色分配给组权限
• 如果角色没有权限条目，则会自动拒绝该角色
• 可以向用户授予覆盖权限
• 超越权限的用户是授予还是拒绝
• 如果无论授予授予"哪个角色，都明确拒绝用户许可，则优先选项将获胜.
• 用户可以扮演多个角色
• 角色可以具有层次结构
• 角色可以从其他角色继承(例如，论坛超级主持人"角色是论坛主持人"，系统维护者"，并且论坛主持人"角色已经从论坛用户"角色继承)
• 从另一个拒绝或授予特权的角色继承的角色将覆盖其子权限
• 权限按模块"分组(例如，博客"模块可以具有编辑输入"权限，而论坛"模块可以具有编辑输入"权限，并且不会发生冲突)
• 具有所有内容"权限，该权限会自动授予完全访问权限

• Roles can be assigned to group permissions
• If the role does not have a permission entry then it is automatically denied
• A user can be given overriding permissions
• A users overriding permissions is either a grant or deny
• If a user is explicitly denied a permission no matter what roles say "granted" the override wins.
• Users can have multiple roles
• Roles can have hierarchy
• Roles can inherit from other roles (e.g. A "Forum Super Moderator" role is a "Forum Moderator", and a "System Maintainer", and the "Forum Moderator" role already inherits from the "Forum User" role )
• Roles that inherit from another role that deny or grant a privilege override their child permission
• Permissions are grouped by "module" (e.g. a "Blog" module can have an "edit entry" permission, and a "Forum" module can have an "edit entry" permission and they will not clash)
• There is a "Everything and Anything" permission that automatically grants full access

因此，这些要求被排除在外，这就是我正在考虑的方式.

So, with those requirements out of the way, here's how I am thinking of doing it.

id            | int     | unique id

表:角色

id            | int     | unique id
--------------|---------------------------------------------
title         | varchar | human readable name

表:权限

id            | int     | unique id
--------------|---------------------------------------------
module        | varchar | module name
--------------|---------------------------------------------
title         | varchar | human readable name
--------------|---------------------------------------------
key           | varchar | key name used in functions

表:Role_User

role_id       | int     | id from roles table
--------------|---------------------------------------------
user_id       | int     | id from users table

表:Permission_Role

id            | int     | unique id
--------------|---------------------------------------------
permission_id | int     | id from permissions table
--------------|---------------------------------------------
role_id       | int     | id from roles table
--------------|---------------------------------------------
grant         | tinyint | 0 = deny, 1 = grant

表:Permission_User

id            | int     | unique id
--------------|---------------------------------------------
permission_id | int     | id from permissions table
--------------|---------------------------------------------
user_id       | int     | id from users table
--------------|---------------------------------------------
grant         | tinyint | 0 = deny, 1 = grant

好吧，实际上只有一半，我确定的一部分，我坚持的部分是层次角色.

Well, actually that's half of it, that part I am sure about, the part I am getting stuck on is the hierarchical roles.

那么，我该如何设计呢? 我的想法是，要保存数据库查询，我将在登录时建立权限矩阵并将其保存到会话中，因此查询不必太简单，因为每次登录只运行一次.

So, how do I design this? My idea is that to save on the database queries I am just going to build the permission matrix on login and save it to session so the queries don't have to be too simple as they are only run once for each login.

我看到的问题是，我需要了解角色的层次结构，以便在解决继承问题之前先解决继承的角色权限.

The issue I see is that, I am going to need to know the hierarchy of the roles so I can resolve the inherited roles permissions before I resolve the inheriting.

用户权限是简单的部分，每用户权限本质上是最终解决的组.

The user permissions is the easy part, the per-user permissions are essentially the finally resolved group.

推荐答案

有一种方法可以通过对表Roles进行递归关系，使角色引用另一条记录来实现角色继承:

There is a way to implement role inheritance by using recursive relation on table Roles, by making role reference to another record:

此关系将在Roles记录内添加1 : n继承.您可以使用此存储的函数获取整个层次树:

This relation will add 1 : n inheritance within Roles record. You might obtain whole hierarchy tree with this stored function:

CREATE FUNCTION `getHierarchy`(`aRole` BIGINT UNSIGNED)
RETURNS VARCHAR(1024)
NOT DETERMINISTIC
READS SQL DATA
BEGIN
DECLARE `aResult` VARCHAR(1024) DEFAULT NULL;
DECLARE `aParent` BIGINT UNSIGNED;

SET `aParent` = (SELECT `parent` FROM `Roles` WHERE `id` = `aRole`);

WHILE NOT `aParent` IS NULL DO

    SET `aResult` = CONCAT_WS(',', `aResult`, `aParent`);
    SET `aParent` = (SELECT `parent` FROM `Roles` WHERE `id` = `aParent`);

END WHILE;

RETURN IFNULL(`aResult`, '');
END

然后，您可能会获得诸如以下所示的所有 granted 权限:

Then, you might obtain all granted permissions with something like this:

SELECT
    `permission_id`
FROM
    `Permission_Role`
WHERE
    FIND_IN_SET(`role_id`, `getHierarchy`({$role}))
    AND
    grant;

如果这还不够，那么您可以做另一个表进行继承:

If it's not enough, then you might do another table for inheritance:

但是，在这种情况下，需要另一种层次结构获取算法.

But, in this case, needed another hierarchy obtainment algorithm.

要解决 覆盖 问题，您将必须获得角色权限和用户权限.然后，将user权限写入session权限，而不是roles权限.

To resolve overriding issue you will have to get role permissions and user permissions. Then, write user permissions over roles permissions to session.

此外，我建议删除Permission_Role和Permission_User中的grant列.无需 映射 每个许可.足以使用EXISTS查询:如果有记录，则授予权限，否则-否.如果需要检索所有权限和状态，则可以使用LEFT JOIN s.

Also, I suggest to remove grant columns in Permission_Role and Permission_User. There is no need to map every permission for each of them. Just enough to use EXISTS queries: if there is a record, then permission granted, else - it's not. If you need to retrieve all permissions and statuses, you might use LEFT JOINs.

这篇关于如何设计基于层次角色的访问控制系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！