Question

我在我的PHP项目中设计了一个非常简单的RBAC（基于角色的访问控制）系统，在给它一些想法之后，我提出了一个解决方案，但是我对构建业务系统并不了解。＃39;我不确定我的解决方案是否存在或将会出现任何重大设计缺陷。

所以基本上，我想给用户一组“角色”＃。我将使用这些角色来允许或拒绝访问应用程序上的某些功能。

这是角色表：

# Roles
    - id [auto-increment, unsigned]
    - role [string, length:50]

# User_Roles
    - user_id [FK:user_id, unsigned]
    - role_id [FK:roles_id, unsigned]

Note: user_id and role_id to be unique index

与我有关的问题是，数据库中没有关于角色实际做什么的信息。但后来我开始思考这是否重要。因为如果角色具有有意义的名称和结构，那么您可以查询user_roles表以获取所有用户角色，然后在代码中查询：

# Fetch user with ID 1 from database
$user = User::find(1);

# Fetch the roles the user has from the database
# @returns : Array of roles
$userRoles = $user->roles()

# $userRoles = ['newmember', 'member.post', 'member.chat']

# Can the user send a message?
if(in_array('member.message', $userRoles)
{
    # User can send a message
}
else
{
    # User can not send a message
}

可以管理角色，并且可以在组织中拥有他们喜欢的任何含义。我只是担心数据库中的角色没有任何意义，我无法帮助，但认为可能是实现这一目标的更好方法。

我的解决方案长期可行吗？

由于

Answer 1

这是我对这种RBAC系统的处理方法，首先我将应用程序拆分为模块，至少在逻辑上是这样。

将模块视为应用程序中可以对其执行某些操作的实体/资源。资源可以是用户，成员资格，产品，......

假设我们正在构建一个类似Stackoverflow的站点，我们有以下模块：

问题（Q＆amp; A部分）
聊天

这些模块中的每一个都在名为modules的应用程序数据库表中注册，它们可能如下所示：

# Modules
  - id [an application-wide unique module identifier, provided by the module]
  - name [string, human readable]

这些模块中的每一个都带有一组由模块预先定义的操作，例如创建问题的操作，从聊天室中踢出用户等。这些操作与模块一起安装到应用程序数据库表中'行动'，看起来像：

# Actions
  - module_id [reference to the modules table, is the namespace for the token]
  - action    [string / int, action identifier provided by the module, unique in the scope of the module]
  - name [string, human readable name]

  - Primary Key: [module_id, action]

现在让我们为Stackoverflow克隆定义模块和操作：

Modules
+------------------------------------------+
| ID        | Name                         |
+------------------------------------------+
| questions | Question and Answer Module   |
| chat      | Chat Module                  |
+------------------------------------------+

除模块外，还将安装操作：

Actions
+-----------------------------------------------+
| Module    | Action    |  Name                 |
+-----------------------------------------------+
| questions | read      | Read Questions        |
| questions | create    | Create Questions      |
| questions | edit      | Edit Questions        |
| questions | delete    | Delete Questions      |
| questions | vote      | Vote on Questions     |
|           |           |                       |
| chat      | join      | Join the Chat         |
| chat      | kick      | Kick users            |
| chat      | create    | Create Chatrooms      |
+-----------------------------------------------+

这里重要的是你不能直接修改这些表中的条目作为系统的管理员，所以没有GUI 添加/删除操作等。

下一步是为我们的系统创建一些角色，这是通过管理员的用户界面完成的，角色可以任意定义。

让我们从一些基本角色开始：

Q&A User:
   - can read questions
   - can create questions
Q&A Moderator:
   - can read questions
   - can create questions
   - can vote on questiosn
   - can edit questions
Q&A Admin:
   - can read questions
   - can create questions
   - can vote on questiosn
   - can edit questions
   - can delete questions

Chat User:
   - can join the chat

Chat Moderator:
   - can join the chat
   - can kick users from the chat

Chat Admin:
   - can join the chat
   - can kick users from the chat
   - can create chat rooms

首先，在角色表中创建角色：

# Roles
    - id [auto-increment, unsigned]
    - name [string, length:50]

填充了我们的自定义定义：

Roles
+-----------------------+
| ID | Name             |
+-----------------------+
| 1  | Q&A User         |
| 2  | Q&A Moderator    |
| 3  | Q&A Admin        |
| 4  | Chat User        |
| 5  | Chat Moderator   |
| 6  | Chat Admin       |
+-----------------------+

在我们超级精彩的管理界面中，我们现在有一个侧边栏，其中包含所有已安装模块及其相关操作的列表。以来我们的典型管理员是超级懒惰的，他对编程一无所知，现在他可以方便地为每个人分配动作拖放的角色，即为角色分配权限。

这些分配的权限存储在我们的映射表Roles_Actions中：

# Roles_Actions
  - role_id
  - module_id 
  - action

  PK: [role_id, module_id, action]

填充的表格：

Roles_Actions
+--------------------------------+
| Role ID | Module ID | Action   |
+--------------------------------+
|    1    | questions |  read    |
|    1    | questions |  create  |
|    2    | questions |  read    |
|    2    | questions |  create  |
|    2    | questions |  vote    |
|    2    | questions |  edit    |
               ...  
|    6    |    chat   |  join    |
|    6    |    chat   |  kick    |
|    6    |    chat   |  create  |
+--------------------------------+

现在我们必须将角色分配给系统中的用户，假设我们最初有四个用户：

- Chuck Norris which is a Q&A Admin and also a Chat Admin (UID = 1)
- Bruce Willis which is a Q&A Moderator and a Chat User   (UID = 2)
- Dilbert which is a Q&A Moderator and a Chat Moderator   (UID = 3)

# User_Roles
   - user_id [FK:user_id, unsigned]
   - role_id [FK:roles_id, unsigned]

填充表：

Users_Roles
+---------------------------------+
| User ID | Role ID               |
+---------------------------------+
|    1    |  3 (= Q&A Admin)      |
|    1    |  6 (= Chat Admin)     |
|    2    |  2 (= Q&A Moderator)  |    
|    2    |  4 (= Chat User)      |
|    3    |  2 (= Q&A Moderator)  |  
|    3    |  5 (= Chat Moderator) | 
+---------------------------------+

因此，一个用户可以拥有多个角色，然后在应用程序层中将权限（模块/操作对）合并在一起。如果你想更进一步，你还可以在角色模型中提供某种继承，例如Q＆amp; A主持人可以定义为Q＆amp; A用户的子级，继承Q＆amp; A用户的所有权限并使用版主权限进行扩展。

那么授权在应用层上怎么样？

让我们假设Dilbert是Q＆amp; A版主和聊天版主登录系统，然后你收集他所有的角色和所有分配给这些角色的权限。接下来，您开始构建权限树并删除所有重复权限，即权限树可以表示为关联数组，如：

Dilbert的许可树：

$dilberts_permissions = array(
   "questions" => array("read", "create", "vote", "edit")
   "chat"      => array("join", "kick")
)

为方便起见，我们创建了一个简单的辅助函数，如：

function has_permission($path, $tree) {
   list($module, $action) = explode('.', $path);
   return (array_key_exists($module, $tree) && in_array($action, $tree[$module]));
}

在我们的代码中，我们现在可以检查是否允许Dilbert使用如下语法执行某些操作：

has_permission("questions.create", $dilberts_permissions);  // => TRUE
has_permission("questions.delete", $dilberts_permissions);  // => FALSE
has_permission("chat.join", $dilberts_permissions);         // => TRUE
has_permission("chat.create", $dilberts_permissions);       // => FALSE

我的基于角色的访问控制是否可行？

1 个答案: