平台应用系统的ACL RBAC ABAC三种权限管理设计模式通俗图解！

设计目标：设计一个灵活、通用、方便的权限管理系统。

权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。

  本文对各种权限管理设计模式进行简要解释，想要重点了解RBAC权限设计模式的

  请移步：RBAC主流通用权限设计模型三大要素：用户，角色，权限解析！

  在这个系统中，我们需要对系统的所有资源进行权限控制，那么系统中的资源包括哪些呢。我们可以把这些资源简单概括为静态资源（功能操作、数据列）和动态资源（数据），也分别称为对象资源和数据资源，后者是我们在系统设计与实现中的叫法。

系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮、数据显示的列以及各种行级数据进行权限的操控。

一.RBAC基于角色的权限设计

权限系统的相关概念，如下：

1.  权限

系统的所有权限信息。权限具有上下级关系，是一个树状的结构。下面来看一个例子

系统管理

        用户管理

               查看用户

                新增用户

                     修改用户

                     删除用户

       对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。

2.       用户

应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。

3.       角色

为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。

4.       组

为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际情况中，我们知道，组也可以具有自己的角色信息、权限信息。这让我想到我们的QQ用户群，一个群可以有多个用户，一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有自己的角色信息，例如普通群、高级群等。

针对上面提出的四种类型的对象，让我们通过图来看看他们之间的关系。

通用权限管理设计篇_设计模式

  有上图中可以看出，这四者的关系很复杂，而实际的情况比这个图还要复杂，权限、角色、组都具有上下级关系，权限管理是应用系统中比较棘手的问题，要设计一个通用的权限管理系统，工作量也着实不小。

当然对于有些项目，权限问题并不是那么复杂。有的只需要牵涉到权限和用户两种类型的对象，只需要给用户分配权限即可。

在另一些情况中，引入了角色对象，例如基于角色的权限系统， 只需要给角色分配权限，用户都隶属于角色，不需要单独为用户分配角色信息。

理清了对象关系之后，让我们接着来进行数据库的设计。在数据库建模时，对于N对N的关系，一般需要加入一个关联表来表示关联的两者的关系。初步估计一下，本系统至少需要十张表，分别为：权限表、用户表、角色表、组表、用户权限关联表、用户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。当然还可能引出一些相关的表。下面让我们在PowerDesigner中画出各表吧。

       各表及其关系如下：

通用权限管理设计篇_设计模式

1.       用户表

通用权限管理设计篇_设计模式

2.       角色表

通用权限管理设计篇_设计模式

3.       权限表

通用权限管理设计篇_设计模式

4.       组表

通用权限管理设计篇_设计模式

5.       角色权限表

通用权限管理设计篇_设计模式

6.       组权限表

通用权限管理设计篇_设计模式

7.       组角色表

通用权限管理设计篇_设计模式

8.       用户权限表

通用权限管理设计篇_设计模式

9.       用户角色表

通用权限管理设计篇_设计模式

10.   用户组表

通用权限管理设计篇_设计模式

11.   组织表

通用权限管理设计篇_设计模式

12.   操作日志表

通用权限管理设计篇_设计模式

以上是主流

再简要介绍下非主流

二.ACL 基于用户的权限控制

ACL（Access Control List）:访问权限列表 如：

user1–>AC1

user1–>AC2

user2–>AC1 此时权限汇总成一个列表

这种设计最常见的应用就是文件系统的权限设计，如微软的NTFS

对权限控制比较分散，不便于管理，
比如无法简单地将一组文件设置统一的权限开放给指定的一群用户

与ACL 对比 RBAC不用给用户单个分配权限， 只用指向对应的角色就会有对应的权限，而且分配权限和收回权限都很方便

三.ABAC（Attribute Base Access Control） 基于属性的权限控制

不同于常见的将用户通过某种方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性来是否满足某种条件来进行授权判断（可以编写简单的逻辑）。属性通常来说分为四类：

1. 用户属性（如用户年龄）
2. 环境属性（如当前时间）
3. 操作属性（如读取）
4. 对象属性（如一篇文章，又称资源属性）

所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。

例如规则：“允许所有班主任在上课时间自由进出校门”这条规则，其中，“班主任”是用户的角色属性，“上课时间”是环境属性，“进出”是操作属性，而“校门”就是对象属性了。为了实现便捷的规则设置和规则判断执行，ABAC通常有配置文件（XML、YAML等）或DSL配合规则解析引擎使用。XACML（eXtensible Access Control Markup Language）是ABAC的一个实现，但是该设计过于复杂，暂不做介绍。

总结一下，ABAC有如下特点：

1. 集中化管理
2. 可以按需实现不同颗粒度的权限控制
3. 不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中
4. 定义权限时，不能直观看出用户和对象间的关系
5. 规则如果稍微复杂一点，或者设计混乱，会给管理者维护和追查带来麻烦
6. 权限判断需要实时执行，规则过多会导致性能问题

既然ABAC这么好，那最流行的为什么还是RBAC呢？

我认为主要还是因为大部分系统对权限控制并没有过多的需求，
而且ABAC的管理相对来说太复杂了。
Kubernetes便因为ABAC太难用，在1.8版本里引入了RBAC的方案。

ABAC有时也被称为PBAC（Policy-Based Access Control）或CBAC（Claims-Based Access
Control）。