【发布时间】:2013-04-14 22:02:19
【问题描述】:
基本交易是,我们为我们的项目定制了一个“kickstart”。为此,我们正在考虑重做用户控件。我知道有很多关于一般 rbac 的问题,但我在分层 rbac 上找不到任何问题?
我们的要求是:
- 角色可以分配给组权限
- 如果角色没有权限条目,则会自动拒绝
- 可以为用户授予覆盖权限
- 用户覆盖权限是授予或拒绝
- 如果用户被明确拒绝权限,则无论哪个角色说“已授予”,覆盖都会获胜。
- 用户可以拥有多个角色
- 角色可以有层次结构
- 角色可以从其他角色继承(例如,“论坛超级版主”角色是“论坛版主”和“系统维护者”,“论坛版主”角色已经从“论坛用户”角色继承)
- 从拒绝或授予权限的其他角色继承的角色会覆盖其子权限
- 权限按“模块”分组(例如,“博客”模块可以有“编辑条目”权限,“论坛”模块可以有“编辑条目”权限,它们不会冲突)
- 有一个“Everything and Anything”权限会自动授予完全访问权限
所以,这些要求已经排除,这就是我的想法。
表:用户
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
嗯,实际上这是一半,我确定的那部分,我卡住的部分是等级角色。
那么,我该如何设计呢? 我的想法是,为了保存数据库查询,我将在登录时构建权限矩阵并将其保存到会话中,这样查询就不必太简单,因为它们每次登录只运行一次。
我看到的问题是,我需要知道角色的层次结构,以便在解决继承问题之前解决继承的角色权限。
用户权限是最简单的部分,每个用户的权限本质上是最终解决的组。
【问题讨论】:
-
user没有role但有permission有什么原因吗?这是一个“许可模型”,而不是“角色模型”,不是吗?使用这种方法,角色不会在任何地方使用。 -
糟糕,忘记添加该表,已编辑!
-
不过,我认为
user没有理由拥有permission。它可能有roles 和permissions,但不是permissions。这件事破坏了逻辑(恕我直言)。 -
@CORRUPT,用户自己也可以被授予权限,这些权限会覆盖他们所在的任何角色。它可以避免仅仅因为您希望用户 X 能够创建具有一个权限的全新角色做一个额外的动作。或者,如果用户一直在做他们不应该做的事情,您可以快速拒绝该用户。否则你将不得不继承最高级别的角色,然后拒绝那里可能会变得混乱。
-
这很像说每个用户都是他们自己的角色,它自动继承自该用户被赋予的所有其他角色,而无需实际为该用户创建一个组。这有意义吗?
标签: php mysql permissions hierarchy rbac