B端后台“权限设计”的99种解法与反思( 二 ) 卫星|水泥|互联网|晶圆厂|钛媒

文章插图
3. 访问控制列表（ACL：Access Control List）ACL（Access Control List）主要包含三个关键要素用户（User）、资源（Resource）和操作（Operate）。
ACL将每一项资源都分配一个列表，当用户需要访问资源时，都会先去请求列表是否有当前用户的访问权限，从而确定当前用户可否执行相应操作。
其优点是，ACL及其简单，不需要任何基础设备就可完成访问控制，但是由于其表单数量过多，导致若系统内部有大量资源，管理访问控制列表就成为了繁琐的工作。

文章插图
4. 基于角色的访问控制制（RBAC：Role-Based Access Control）
RBAC模型是在实际业务中使用最多的模型，RBAC模型主要由3个基础模块组成，分别为用户、角色、权限。系统通过编辑用户与角色、角色与权限的映射关系，解耦用户与权限的关系，大幅度降低数据冗余，进而降低了系统的复杂度，提高了系统的灵活性。
RBAC模型它只是一个大类，它可以细致地划分为：RBAC0、RBAC1、RBAC2、RBAC3。
1）基本模型：RBAC0
RBAC0是RBAC的核心，它定义了能构成RBAC控制系统的最小元素的集合（角色）。在此模型中，它指明了角色、用户、访问权限和会话之间的关系。其流程为，通过用户关联角色，定义权限集（角色）的方法间接的赋予用户权限，进而达到用户和权限解耦的目的。

文章插图
在RABC中，用户与角色的关系可以分为为“N：1（多对一）的用户角色关系”和”N:N（多对多）的用户角色关系“。
举个N：1的用户角色关系的例子，李三、李四（用户）都是A部门（用户组）的人，岗位都为产品运营（角色），他们都需要文章审核、文章发布功能（权限）。因此，只需要对产品运营（角色）进行分配文章审核、文章发布（权限），将产品运营（角色）分配给李三、李四即可。

文章插图
N：N（多对多）的用户角色关系中，若一个用户被分配了多个角色，那么该用户的权限为所分配角色的并集。
再举个例子，李五为B部门的产品经理，权限为文章模板设置。但是因为某次调研，他需要A部门的文章审核、发布权限。当分配给他A部门产品运营角色后，此时，他的权限变成了文章审核、发布权限、文章模板设置。

文章插图
但在实际业务中，对于用户的理解并非如上文中所写的那么浅薄。实际上，对于用户的定义多种多样，就笔者自身对用户的理解而言：“用户本质上为一个个需求的集合体“。
从这个角度来讲，在使用场景和需求相对一致的情况下，可以将这部分用户看作一个需求集合体一致的群组，进而形成一个用户组（即为用户的集合体）。
拿之前的例子来说，若A部门为产品运营部，那么我们无需对A部门内部的人去分配角色。而是以A部门为对象去分配角色。

文章插图
同时，现实中同样也存在以下使用场景，需要对用户分配居多的权限，若一个个分配将特别繁琐，因而可以选择将相对固定的权限打包成组来赋予给用户。

文章插图
2）角色分层模型：RBAC1
RBAC1在RBAC0的基础上，引入角色间的继承关系，即角色上有了上下级的区别。角色间的继承关系可分为一般继承关系和受限继承关系。

文章插图
一般继承关系仅要求角色继承关系是一个绝对偏序关系（有向无环图），可进行多继承。而受限继承关系则进一步要求角色继承关系是一个树结构（二叉树）间的单继承。
一般继承的RBAC和受限继承的RBAC两者的区别在于：前者是图，可多继承；而后者可以有多个父节点但只能有一个子节点，是一个反向树结构，只能单继承。

文章插图
RBAC1模型往往使用于角色之间层级明晰的产品中，一般会和组织架构关联起来。例如，李三为产品运营，其上级李四为产品经理。则李四会将其部分权限授权给李三，也可认定为李三继承了李四的部分权限，即子集继承了父级部分权限。