权限控制的设计方式

目前主流的权限模型有两种：

• 
  基于角色的访问控制（RBAC）
  
• 
  基于属性的访问控制（ABAC）
  

RBAC模型

基于角色的访问控制（Role-Based Access Control，简称 RBAC），指的是通过用户的角色（Role）授权其相关权限，实现了灵活的访问控制，相比直接授予用户权限，要更加简单、高效、可扩展。



当使用 RBAC模型 时，通过分析用户的实际情况，基于共同的职责和需求，授予他们不同角色。这种

用户 -> 角色 -> 权限

间的关系，让我们可以不用再单独管理单个用户权限，用户从授予的角色里面获取所需的权限。

以一个简单的场景（Gitlab 的权限系统）为例，用户系统中有 Admin、Maintainer、Operator 三种角色，这三种角色分别具备不同的权限，比如只有 Admin 具备创建代码仓库、删除代码仓库的权限，其他的角色都不具备。我们授予某个用户 Admin 这个角色，他就具备了 创建代码仓库 和 删除代码仓库 这两个权限。

通过 RBAC模型 ，当存在多个用户拥有相同权限时，我们只需要创建好拥有该权限的角色，然后给不同的用户分配不同的角色，后续只需要修改角色的权限，就能自动修改角色内所有用户的权限。

ABAC模型

基于属性的访问控制（Attribute-Based Access Control，简称 ABAC）是一种比 RBAC模型 更加灵活的授权模型，它的原理是通过各种属性来动态判断一个操作是否可以被允许。这个模型在云系统中使用的比较多，比如AWS，阿里云等。

考虑下面这些场景的权限控制：

授权某个人具体某本书的编辑权限

当一个文档的所属部门跟用户的部门相同时，用户可以访问这个文档

当用户是一个文档的拥有者并且文档的状态是草稿，用户可以编辑这个文档

早上九点前禁止 A 部门的人访问 B 系统

在除了上海以外的地方禁止以管理员身份访问 A 系统

用户对 2022-06-07 之前创建的订单有操作权限

可以发现上述的场景通过 RBAC模型 很难去实现，因为 RBAC模型 仅仅描述了用户可以做什么操作，但是操作的条件，以及操作的数据，RBAC模型 本身是没有这些限制的。但这恰恰是 ABAC模型 的长处，ABAC模型 的思想是基于用户、访问的数据的属性、以及各种环境因素去动态计算用户是否有权限进行操作。

ABAC模型的原理

在 ABAC模型 中，一个操作是否被允许是基于对象、资源、操作和环境信息共同动态计算决定的。

对象：对象是当前请求访问资源的用户。用户的属性包括ID，个人资源，角色，部门和组织成员身份等

资源：资源是当前用户要访问的资产或对象，例如文件，数据，服务器，甚至API

操作：操作是用户试图对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”

环境：环境是每个访问请求的上下文。环境属性包含访问的时间和位置，对象的设备，通信协议和加密强度等

在 ABAC模型 的决策语句的执行过程中，决策引擎会根据定义好的决策语句，结合对象、资源、操作、环境等因素动态计算出决策结果。每当发生访问请求时，ABAC模型 决策系统都会分析属性值是否与已建立的策略匹配。如果有匹配的策略，访问请求就会被通过。