权限系统设计

很多人都知道以角色为基础的 权限管理 设计（RBAC），但是大部分人似懂非懂，不知道完整的权限管理系统都包括哪些内容。

   在此以权限管理的使用场景来说明一下完整的权限管理内容。

一是鉴权管理 ，即权限判断逻辑。

   1. 最基本的权限管理就是菜单管理，用户没有权限的功能模块在菜单节点上是不显示的。（很多人以为这就是权限管理！）

      示例：普通业务人员登录系统后，是看不到【用户管理】菜单的。

   2. 功能权限管理，B/S系统的功能体现为URL，所以功能权限管理主要是针对URL访问的管理。（很多人都不清楚权限管理的对象是什么？）

      示例：

      经过授权，部门经理可以查看【用户管理】菜单，并查看部门用户信息，但权限设计要求，该部门经理没有添加用户的权限。

      所以在访问【添加用户】的功能（URL）时，应该有没有授权的提示信息。

      同时在【用户管理】页面上，【添加用户】的按钮应该灰色显示，不能点击。

   3. 行级权限管理

      示例：

      论坛管理员，权限设计要求 A能管理论坛 【新闻版块】，不能管理论坛 【技术交流】

      此时的权限设计就应该根据论坛的相应ID来判断权限信息。

   4. 列级权限管理

      示例：

      业务权限设计要求，除销售人员以外，其他用户不能看到客户的联系方式信息。

      此时的权限设计要判断相应的字段（列）是否可以显示。

   5. 组织机构/部门级数据权限管理

      示例:

      业务权限设计要求，销售一部的人员只能看到本部门的销售订单，销售二部的人员只能看到本部门的销售订单，但销售经理可以同时看到

      销售一部和销售二部的销售订单。

      此时的权限设计就要根据销售订单数据本身的部门属性来做判断

   6. 范围型业务数据权限管理

      示例：

      大卖场销售人员在下销售订单时，要选择相应的产品所在仓库信息。

      业务权限设计要求，【国美】的销售人员在选择仓库的下拉列表中不能看到【广州仓库】，而【大中电器】的销售人员在选择仓库的下拉列表中不能看到【北京顺义仓库】

二是授权管理 ，即权限分配过程。以上的权限管理内容都要通过系统的授权功能来分配给具体的用户，授权功能应该足够灵活。

   1. 直接对用户授权，直接分配到用户的权限具有最优先级别。

   2. 对用户所属岗位授权，用户所属岗位信息可以看作是一个分组，和角色的作用一样，但是每个用户只能关联一个岗位信息。

   3. 对用户所属角色授权，用户所属角色信息可以看作是一个权限分组，每个用户可以关联多个角色。

   4. 角色直接关联具体的功能权限（URL），也可以关联负权限，即此角色关联的权限不能使用负权限功能。负权限具有优先级别。

   5. 分级授权，系统管理员可以将自己拥有的权限信息授权给其他用户。即可以设置分级管理员和超级管理员。

   以上才是一个完整的权限管理系统，你有这样的完整权限的设计吗？

权限管理是所有后台系统的都会涉及的一个重要组成部分，主要目的是对不同的人访问资源进行权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。

迄今为止最为普及的权限设计模型是RBAC模型,基于角色的访问控制（Role-Based Access Control)

RBAC-0模型是权限最基础也是最核心的模型,它包括用户/角色/权限,其中用户和角色是多对多的关系,角色和权限也是多对多的关系。

用户 是发起操作的主体,按类型分可分为2B和2C用户,可以是后台管理系统的用户,可以是OA系统的内部员工,也可以是面向C端的用户,比如阿里云的用户。

角色 起到了桥梁的作用,连接了用户和权限的关系,每个角色可以关联多个权限,同时一个用户关联多个角色,那么这个用户就有了多个角色的多个权限。

有人会问了为什么用户不直接关联权限呢？在用户基数小的系统,比如20个人的小系统，管理员可以直接把用户和权限关联，工作量并不大，选择一个用户勾选下需要的权限就完事了。

但是在实际企业系统中，用户基数比较大,其中很多人的权限都是一样的，就是个普通访问权限，如果管理员给100人甚至更多授权,工作量巨大。

这就引入了 "角色(Role)" 概念,一个角色可以与多个用户关联,管理员只需要把该角色赋予用户,那么用户就有了该角色下的所有权限,这样设计既提升了效率,也有很大的拓展性。

权限 是用户可以访问的资源,包括页面权限,操作权限,数据权限:

以上是RBAC的核心设计及模型分析,此模型也叫做RBAC-0,而基于核心概念之上,RBAC还提供了扩展模式。包括RBAC-1,RBAC-2,RBAC-3模型。下面介绍这三种类型

此模型引入了角色继承(Hierarchical Role)概念，即角色具有上下级的关系，角色间的继承关系可分为一般继承关系和受限继承关系。

一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。

而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。

基于核心模型的基础上，进行了角色的约束控制，RBAC2模型中添加了责任分离关系。

其规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

责任分离包括静态责任分离和动态责任分离。主要包括以下约束:

即最全面的权限管理,它是基于RBAC-0，将RBAC-1和RBAC-2进行了整合。

当平台用户基数增大，角色类型增多时，而且有一部分人具有相同的属性，比如财务部的所有员工，如果直接给用户分配角色，管理员的工作量就会很大。

如果把相同属性的用户归类到某用户组，那么管理员直接给用户组分配角色，用户组里的每个用户即可拥有该角色，以后其他用户加入用户组后，即可自动获取用户组的所有角色，退出用户组，同时也撤销了用户组下的角色，无须管理员手动管理角色。

根据用户组是否有上下级关系,可以分为有上下级的用户组和普通用户组:

每个公司都会涉及到到组织和职位,下面就重点介绍这两个。

我们可以把组织与角色进行关联，用户加入组织后，就会自动获得该组织的全部角色，无须管理员手动授予，大大减少工作量，同时用户在调岗时，只需调整组织，角色即可批量调整。

组织的另外一个作用是控制数据权限,把角色关联到组织,那么该角色只能看到该组织下的数据权限。

每个组织部门下都会有多个职位，比如财务部有总监，会计，出纳等职位，虽然都在同一部门，但是每个职位的权限是不同的，职位高的拥有更多的权限。

总监拥有所有权限，会计和出纳拥有部分权限。特殊情况下,一个人可能身兼多职。

根据以上场景,新的权限模型就可以设计出来了,如下图:

根据系统的复杂度不同,其中的多对多关系和一对一关系可能会有变化

授权即给用户授予角色,按流程可分为手动授权和审批授权。权限中心可同时配置这两种,可提高授权的灵活性。

有了上述的权限模型,设计表结构就不难了,下面是多系统下的表结构,简单设计下,主要提供思路:

在项目中可以采用其中一种框架,它们的优缺点以及如何使用会在后面的文章中详细介绍。

权限系统可以说是整个系统中最基础，同时也可以很复杂的，在实际项目中，会遇到多个系统，多个用户类型，多个使用场景，这就需要具体问题具体分析，但最核心的RBAC模型是不变的,我们可以在其基础上进行扩展来满足需求。

一 RBAC模型

    目前，接受度较高的功能权限模型是RBAC（Role-Based Access Control）模型。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。

1.角色的作用

如果没有角色的概念，直接用户对应权限，虽然会更加灵活，但是后台的数据表设计会变得复杂，操作成本也会很高，同时容错能力也会变得很差。

而引入“角色”概念后，用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。此时只需要为角色赋予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性，同时整个设计的容错能力也提高了很多。

2.引入用户组

  一些大型的平台上，如果用户数量较大，新增角色时，需要为大量用户分配新的角色，工作量巨大，此时可以引入用户组的概念，将这些用户拉到同一个用户组中，然后对整个用户组进行角色的指定，这就大大减少了角色分配的工作量。

同理如果权限较多时也会存在一样的问题，对角色进行权限设置时也需要大量的操作，此时可以考虑引入权限组的概念，将关联性较强的权限大包成组赋予角色，从而减少赋值时的工作量，现实中权限组的使用相对较少，因为系统中的权限一般来讲是有限的。需要注意的是即使有用户组或权限组的存在，也可以允许用户或权限与角色直接关联，这个可以视具体业务情况而定。

下图所示为mac系统中运行添加用户组，并以用户组为单位配置权限。

3. 角色继承的RBAC模型

在一个业务场景中，如果角色需区分：设计主管、设计组长、设计成员，并且管理方式为向下兼容时，则需使用角色继承的RBAC模型。上层角色继承下层角色的全部权限，且可额外赋予权限。

此时除了对角色进行定义，还需要管理角色间的关系，通过关系来体现角色的层级关系，从而达到继承权限的效果。角色的继承关系主要有两种：树形图和有向无环图。

继承关系常常来源于公司团队的组织结构，此时常将角色与组织结构进行关联达到继承角色模型的效果。如下图所示的赵同学，其角色是“三级团队负责人”，与其并列的小组中有多个“三级团队负责人”的角色，但依附于左侧的组织结构树，各级负责人仅有查看和操作自己下属子节点的权限。

4. 限制的RBAC模型

在一个产品或系统中，部分角色可能是需要隔离的、不允许被同时赋予一个人的。跟大家熟知的“不能既是‘运动员’又是‘裁判员’ ”一个道理。

因此，对于众多角色中的一组，只能是单选的关系，但多组角色之间可以共同存在。如下图中，一个用户可以既为设计师又为管理员，但在设计师角色组中仅能被赋予一个角色，在管理员角色组中也仅能被赋予一个角色。

此外，限制还有可能是数量上的，比如一个产品组中必须有且只有一个管理员，不允许删除或再分配管理员角色，仅允许将负责人角色变更。

限制的模型不仅仅对分配过程产生影响，有时即使拥有了多种角色，因为不同的角色对同一个功能的使用方式或数据会产生冲突，所以使用时也需要进行限制。如下图所示为同一时间仅允许以一个身份登录。

根据不同的业务需求，限制的形式很多。需要注意的是不能仅依赖后端限制，而是要在前端展示清晰的规则和恰当的限制，避免用户出错和沮丧。

三、权限的拆分与设计

通过RBAC模型已经能够很好的搭建起用户、角色与权限之间的关系了。但具体是什么样的关系，以及“权限”这个抽象的概念具体如何规划？

这些都需要分析清楚才能进一步设计出完善的权限系统。

首先需要知道，一般产品的权限由页面、操作和数据构成。页面与操作相互关联，必须拥有页面权限，才能分配该页面下对应的操作权限。数据可被增删改查。

整体关系如下图所示：

因此，在设计之初我们就需要考虑到未来可能区分角色的地方，尽量解耦、模块化。对于技术来说，每一个页面模块、每一个操作都最好使用独立的接口。对于设计来说，需要保障所有角色因为权限而屏蔽掉部分操作和数据后，页面和流程仍能体验流畅。

保证初期设计支持后，配置权限时，还需要注意以下几点：

（1）确定是否支持前端配置

如果角色和权限相对固定，则一般将角色与权限的关系可以写在后台，改动时需要后端变更且重新上线。这种情况适用于公司内部系统等只有一个使用主体的系统。

如果需要自定义角色或者每个角色在不同使用者的场景下有不同的权限，则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面”。这种情况适用于有频繁变动的自定义角色权限，和有租户体系的系统。

（2）以基本单元拆分，以业务逻辑配置

一般可将每个对象的“增、删、改、查”各自作为一个基本的权限单元。打个比方，在“人员管理”中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上，我们希望能尽量做到解耦和模块化。

但是在业务层面有些操作却是一体的。这些不能拆开的权限在“前端用户配置页面”中建议打包成一个整体提供配置。例如：如果我们确定在系统的现有和未来业务中，仅分为普通成员有“人员管理”的查看权限，管理员有操作权限，则可将“增、删、改”三个基本权限单位合并为“操作”权限进行配置。

（3）页面权限优先于操作和数据权限

必须配置了页面模块权限后，才能配置当前页面模块下具体的操作权限，以及页面模块的数据展示权限。

（4）查看权限优先于增删改权限

正常情况下，一定要先能查看某个模块或操作，其它的增删改操作才有意义。因此在设计时，应在获取查看权限前限制其它权限的配置，或者配置其它权限时默认赋予查看权限。

（5）角色与权限的多种关系

角色与权限的关系不仅是单纯“是/否关系”，还包括以某种限制进行操作，和以某种程度访问数据。

例如在“人员管理”中：

数据范围：用户拥有查看人员列表的权限，但仅能查看自己所在的团队；数据边界限制（上限等）：添加人员时不能超过20个等。数据字段：HR能查看人员列表中包括职级、薪资等字段，其它角色仅能查看姓名邮箱等字段；

（6）角色与权限的设计表达

在传达一个系统的权限设计规则时，设计师常常习惯用主观最直接的方式表达想法，如用“当……时，就……”的句式来表达。但一个平台中涉及的权限规则是非常多的，当通篇以这样的形式描述时，表达对象将很难理解。

正确的描述方式：更清晰的是基于开发的语言，和技术模型的结果进行表达。将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。

如下图所示：

四、需要注意的Tips

1. 隐形的admin

在可自定义角色和权限的系统中，一般需要预留一个admin角色来进行系统的初始配置，用于添加首批的业务人员和配置基本的角色。

有的系统中允许存在上帝视角的admin角色，则其可以作为“超级管理员”显示在角色配置的列表中。有的系统中不允许这种角色存在，则可将这种角色设置为隐形的状态，仅赋予维护系统的工作人员。

2. 初始权限的赋予

对于允许用户自行加入的系统，需要设定一至多个默认的角色，有时可以是仅有最基础权限的“游客”角色。

初始权限还可以与用户既有的某些数据字段进行关联，如添加用户时获取到用户的岗位为“设计师”，则直接赋予“设计师”角色的权限。

3. 人员管理中对自己的处理

在人员管理中，管理员角色处理自己时需要额外注意。因为如果修改或删除了自己角色后，可能导致系统没有管理角色，从而无法添加其他成员和正常运行。设计时可添加判断，当自己为唯一管理角色时，禁止编辑和删除。

4. 无页面权限的提示

虽然可以通过页面权限限制直接隐藏当前用户没有权限的页面，但不能排除用户获取到权限外的url地址。当用户意外访问到没有权限的页面时务必提供“无权限”的提示，避免用户认为系统bug。

总结一下，整个权限系统设计就是定义各个节点和节点间关系的过程。

节点包括：

用户；用户组；角色；角色组；权限（页面、操作、数据）；权限组（页面、操作、数据）；

一、基础知识

二、权限设计一般流程

三、功能权限&数据权限

四、参考资料

一、基础知识

RBAC（role based access control）模型，（基于用户角色的访问控制）

二、模型的不同分类

1.基本模型RBAC0： 可以引入用户组/权限组的概念

-用户

-角色

-会话：会话是动态的概念，用户必须通过会话才可以设置角色，是角色与激活的角色之间的映射关系。

-许可（操作和控制对象）

2.RBAC1角色分层模型

RBAC1在RBAC0基础上角色新增继承概念。比如，销售经理/销售副经理

来源于公司团队的组织结构，将角色与组织结构进行关联达到继承角色模型的目的

-用户

-角色+继承：角色就有了上下级或者等级关系

-会话

-许可

比如：上层角色继承下层角色的全部权限且可额外赋予权限

角色的继承关系：

-树形图

-有向无环图

3.RBAC2角色限制模型

RBAC0基础上假设“约束”概念，引入静态职责分离SSD和动态职责分离DSD概念。

DSD 是会话和角色之间的约束，可以动态约束用户拥有的角色，如一个用户可以拥有两个角色，运行时只能激活一个角色。

SSD ：用户和角色的指派阶段加入，对用户和角色有如下约束：

-互斥角色：同一个用户在两个互斥角色中只能选择一个

-基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的

-先决条件约束:用户想要获得高级角色，首先必须拥有低级角色

4.RBAC3统一模型

它是RBAC1+RBAC2合集，用于复杂情况下对权限系统进行考虑。

二、权限设计一般流程

1.权限设计一般逻辑

1）抽象出对产品有诉求的的多个角色

2）依据角色的特性梳理使用场景并设计

举例：

-当角色之间的使用场景不冲突，则不需要隔离，如网易云音乐的电台和听歌功能

-当角色之间的使用场景完全不相关，流程对立时，设计完全独立的两个系统，如滴滴的司机端和用户端

-当角色和使用场景部分隔离部分通用，则引入权限管理的内容

2.权限的拆分和设计

整体思路：

产品的权限由 页面、操作和数据 构成。页面与操作关联，先有页面权限再分配页面权限下的对应的操作权限，如图所示

基本点：

1）.权限操作是否支持前端配置：适用于有频繁变动的自定义角色权限，比如，租户体系的系统

2）.每个对象中，“增删改查”各自作为一个基本单元，拆分为4个权限单元。

3）.首先获取页面权限，才能够配置当前页面下的操作和数据权限

4）.查看权限优先于操作权限，现有查看再有操作

5）.角色和权限之间的多种关系

6）.表达方式：基于开发语言和技术模型进行表达，如图

小tips注意点：

三、功能权限&数据权限

1.功能权限

1）.功能的粒度

模块级>页面级>接口级（接口级别的功能权限是指哪个角色能调用哪些接口）

2）.功能的优先级

优先级规律：只要分配低优先级的功能必须先分配高优先级的功能。（比如，给操作权限没给查看权限，但是按钮的操作在页面上，得先给查看权限才能进行操作）

一般优先顺序为：查看详情>查看列表>增加、删除、编辑、其他操作按钮。

3）.跨模块的问题

跨模块分析的，模块A中能访问链接，链接为模块B中的内容

方法一：模块A中只可通过链接访问B模块

方法二：既有A又有B权限的人才可访问

2.数据权限

解决用户能看到多少数据量和看到什么数据的问题

1）.数据权限也企业的组织结构有关系，组织架构一般分为树状和扁平状

2）.节点间的数据共享方式，如图，假设已经拥有功能权限

ps：数据权限定义过程中如果出现同一节点下【用户间层级问题（上下级）】需要回归功能权限的【角色定义】去解决。

3.角色权限系统配置

将数据权限、功能权限糅合到角色里，再行分配给用户

从用户操作层面看，选择角色的过程中完成了功能权限的配置，数据权限早已随着他的所属结点确定。

从架构设计层面看，一开始是分开设计的，一般先做功能权限，最后会数据和功能结合看。但没有既定的规则，想清楚就好。

参考资料：

随着互联网的快速发展，B端行业也逐渐崛起，很多企业管理中使用的软件我们通常称其为B端管理系统，而在B端系统中“权限管理”是必不可少的功能，不同的系统中权限的应用复杂程度不一样，都是根据实际产品以及需求情况而设置合理的权限。而我们现在对于权限的设置基本上都是建立在RBAC权限模型上的、扩展的，下面我会通过介绍RBAC权限模型的概念以及结合实际业务情况列举权限设置的应用。

二、什么是RBAC权限模型？

RBAC是Role-BasedAccess Control的英文缩写，意思是基于角色的访问控制。RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What进行How的操作，也就是“主体”对“客体”的操作。其中who是权限的拥有者或主体（例如：User、Role），what是资源或对象（Resource、Class)。

简单的理解其理念就是将“角色”这个概念赋予用户，在系统中用户与权限之间通过角色进行关联，以这样的方法来实现灵活配置。

RBAC其实是一种分析模型，主要分为：基本模型RBAC0、角色分层模型RBAC1、角色限制模型RBAC2和统一模型RBAC3。

RBAC权限模型是基于角色的权限控制。模型中有几个关键的术语：

用户：系统接口及访问的操作者

权限：能够访问某接口或者做某操作的授权资格

角色：具有一类相同操作权限的用户的总称

1）RBAC0

RBAC0是RBAC权限模型的核心思想，RBAC1、RBAC2、RBAC3都是在RBAC0上进行扩展的。RBAC0是由四部分构成：用户、角色、会话、许可。用户和角色的含义很简单，通过字面意思即可明白，会话：指用户被赋予角色的过程，称之为会话或者是说激活角色；许可： 就是角色拥有的权限（操作和和被控制的对象），简单的说就是用户可使用的功能或者可查看的数据。

用户与角色是多对多的关系，用户与会话是一对一的关系，会话与角色是一对多的关系，角色与许可是多对多的关系。

2）RBAC1

RBAC1是在RBAC0权限模型的基础上，在角色中加入了继承的概念，添加了继承发的概念后，角色就有了上下级或者等级关系。

举例：集团权责清单下包含的角色有：系统管理员、总部权责管理员、区域权责管理员、普通用户，当管理方式向下兼容时，就可以采用RBAC1的继承关系来实现权限的设置。上层角色拥有下层的所有角色的权限，且上层角色可拥有额外的权限

3）RBAC2

RBAC2是在RBAC0权限模型的基础上，在用户和角色以及会话和角色之间分别加入了约束的概念（职责分离），职责分离指的是同一个人不能拥有两种特定的权限（例如财务部的纳入和支出，或者运动员和裁判员等等）。

用户和角色的约束有以下几种形式:

互斥角色：同一个用户在两个互斥角色中只能选择一个（也会存在一个用户拥有多个角色情况，但是需要通过切换用户角色来实现对不同业务操作）

基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的

先决条件约束：用户想要获得高级角色，首先必须拥有低级角色

会话和角色之间的约束，可以动态的约束用户拥有的角色，例如一个用户可以拥有两个角色，但是运行时只能激活一个角色。

例如：iconfont和蓝湖的用户与角色就采用了约束的概念，超级管理员只允许只有一个

4）RBAC3

RBAC3是RBAC1与RBAC2的合集，所以RBAC3包含继承和约束。

二、为什么要引用RBAC权限模型？

RBAC中具有角色的概念，如果没有角色这个概念，那么在系统中，每个用户都需要单独设置权限，而系统中所涉及到的功能权限和数据权限都非常多，每个用户都单独设置权限对于维护权限的管理员来说无疑是一件繁琐且工作量巨大的任务。

而引入角色这个概念后，我们只需要给系统设置不同的角色， 给角色赋予权限，再将用户与角色关联，这样用户所关联的角色就直接拥有了该角色下的所有权限。

例如：用户1~用户8分别拥有以下权限，，不同用户具有相同权限的我用不同的颜色做了区分，如下图：

在没有引入RBAC权限模型的情况下，用户与权限的关系图可采用下图的杨叔叔展示，每个用户分别设置对应的权限，即便是具有相同权限的用户也需要多次设置权限。

引入RBAC权限模型及引入了角色的概念，根据上面表格的统计，用户1、用户3、用户5、用户8拥有的权限相同，用户2、用户6、用户7拥有相同的权限，用户4是独立的权限，所以我们这里可以根据数据统计，以及实际的需求情况，可以建立三个不同的角色，角色A、角色B、角色C，三个角色分别对应三组用户不同的权限，如下图所示：

对应的上面的案例表格我们就可以调整为含有角色列的数据表，这样便可以清楚的知道每个用户所对应的角色及权限。

通过引用RBAC权限模型后，对于系统中大量的用户的权限设置可以更好的建立管理，角色的引入让具有相同权限的用户可以统一关联到相同的的角色中，这样只需要在系统中设置一次角色的权限，后续的用户便可以直接关联这些角色，这样就省去了重复设置权限的过程，对于大型平台的应用上，用户的数量成千上万，这样就可避免在设置权限这项工作上浪费大量的时间。

三、引入用户组的概念

我们依旧拿上面表格案例举例，虽然前面我们应用的RBAC权限模型的概念，但是对于大量用户拥有相同权限的用户，我们同样的也需要对每个用户设置对应的角色，如果一个部门上万人，那么我们就需要给这个部门上万人分别设置角色，而这上万其实是具有相同的权限的，如果直接采用基础的RBAC权限模型的话，那么面对这样的情况，无疑也是具有一个庞大的重复的工作量，并且也不利于后期用户变更的维护管理，那么针对相同用户具有相同的权限的情况，我们便可以引入用户组的概念。

什么是用户组呢？ 用户组：把具有相同角色的用户进行分类。

上面我们的数据表格案例中的用户1、用户3、用户5、用户8具有相同的角色A，用户2、用户6、用户7也拥有相同的角色B，那么我们就可以将这些具有相同角色的用户建立用户组的关系，拿上面的案例，我们分别对相同角色的用户建立组关系，如下：

用户1、用户3、用户5、用户8→建立用户组1

用户2、用户6、用户7→建立用户组2

因为用户4只有一个用户，所以直接还是单独建立用户与角色的关系，不需要建立用户组，当然尽管只有一个用户也是可以建立用户组的关系，这样有利于后期其他用户与用于4具有相同的角色时，就可以直接将其他用户添加到这个用户组下即可，根据业务的实际情况而选择适合的方案即可。

通过案例表格的变化我们就可以直观的看出权限设置变得清晰简洁了，通过第用户组赋予角色，可以减少大量的重复的工作，我们常见的企业组织、部门下经常会出现不同用户具有相同角色的情况，所以采用用户组的方式，便可以很好的解决这个问题，给具有相同权限的用户建立用户组，将用户组关联到对应的角色下，此用户组就拥有了此角色下的所有权限，而用户是属于用户组的，所以用户组下的所有用户也就同样的拥有了此角色下的所有权限。一个用户可以属于多个用户组，一个用户组也可以包括多个用户，所以用户与用户组是多对多的关系。

四、引入权限组的概念

权限组与用户组的原理差不多，是将一些相对固定的功能或者权限建立组的关系，然后再给此权限组赋予角色，目前我所接触的B端项目中使用权限组的概念的比较少，可简单的看一下关系图

四、功能权限和数据权限

B端系统中一般产品的权限由页面、操作和数据构成。页面与操作相互关联，必须拥有页面权限，才能分配该页面下对应的操作权限，数据可被增删改查。所以将权限管理分为 功能权限管理和数据权限管理。

功能权限管理：指的是用户可看到那些模块，能操作那些按钮，因为企业中的用户拥有不同的角色，拥有的职责也是不同的。

数据权限管理：指的是用户可看到哪些模块的哪些数据。

例如：一个系统中包含多个权责清单（清单1、清单2、清单3），系统管理员能对整个系统操作维护。。。。。

完整内容请查看公众号原文链接

原文链接：B端产品之权限设计（RBAC权限模型）

来源公众号《设计小余》

权限能力包括两类：数据权限、系统操作权限

有的人会好奇，为什么前端产品会有有权限管理的要求？接下来我将以角色、权限、以及RABC权限设计方法来概述权限设计、数据权限设计2个操作。

了解权限系统前，首先要定义角色，角色的分类如下

最高权限角色

超级管理员，这个角色一般为平台创建者。可以拥有最高权限，可分配所有的系统权限到其他用户，一般是把最高权限设计还会映射一个超级管理员作为副管理，方便删除、编辑人员

副管理员角色

副超级管理员，仅次于最高权限，可以分配自己权限下的以外权限。显然在他之上就是超级管理员权限

部分权限所有者角色

是指的是在副管理员下，有子权限的用户。比如在副管理员分层下的权限

特约用户角色

只是定向权限开通，同事这样的用户有大量的。比如PMTalk产品经理社区的签约作者

付费用户角色

付费用户权限在针对产品生命周期早期是与免费直接区分，随着付费用户精细化运营打造用户分层，比如QQ会员的超级会员、普通会员等

角色之间的关系如下，可以看见在超级管理员角色下以树状结构分布到子角色。

▲   角色之间关系  

基于角色权限控制的RABC权限思想

依次为理论的角色设计模型关系图

▲   RABC角色权限  

上图是基于用户的会话集合归位角色再分配权限。角色有操作和控制对象的权利，在基础上将用户权限系统氛围：用户管理、角色管理、权限管理。

实际上用户管理在系统早期是可以满足权限使用，但随着系统用户、公司扩张逐渐增多，可能用户会有因为部门的职责区别，造成了部门下的同用户权限是一样的。

因此产品经理务必要在用户管理上增加部门管理对角色区分。

▲   部门管理  

将部门架构的编辑、添加、管理都以系统化的方式管理。

看到部门之间的流转关系，还可以知道部门下有什么基础权限。比如运营部门肯定会涉及到公众号管理、客服号管理，所以在以下部门的员工都要求设置。

同个部门中存在多个角色，比 如上有运营总监、副总监、组长、用户，因此权限要给到每个部门负责人进行编辑、删除、添加。

让权限管理者降低了日常运营权限工作量，将权限分配能力分配给了其他成员。

▲   网上来自部门角色权限管理的配置图  

用户管理，给与用户授权角色

最普遍的做法是设计用户名单列表，针对用户信息进行编辑。

用户管理列表如上，可以操作用户属于封禁状态与否、查看用户先有状态。

每个角色下的权限设置，可以编辑权限、和删除权限。以及批量同意权限

设置好角色后，还可以在角色下查看已经开通的用户名单，对用户名单进行管理。

用户名单进行删除、添加。同时当前页面需要下可以展示多少用户、是否需要分页也要注意明确。

2.添加/创建用户

为系统添加新的管理人员，增加权限。增加手机号、邮箱、用户名称，如果企业使用了OA系统，可以和OA系统进行关联。

比如现在的企业微信、钉钉都是支持开放接口，快速同步员工信息。

3.创建添加账户管理流程

系统建设好后，接下来就是规范运营了。以账户开通来说要建立账户开通权限流程规范，比如下图是某个公司开通运营系统管理员权限的流程

▲   系统权限创建流程

上图“选择字段”可以理解为权限下的子权限。若系统不复杂可以不用在早起权限设计上增加子权限颗粒度。

我们需要先设置角色，给新账号关联对应的角色，如果账号有特殊权限或者相关字段的权限，再单独设置相关字段。

最后基于RABC角色权限系统设置，产品经理可以借鉴的一个思考脑图案例

完成权限设计后，要搭建权限表单。快速罗列各个角色下的权限通道

▲   

数据权限的设计

操作权限是比较容易做的，但数据权限则比较难了。甚至许多互联网公司都没有考虑数据权限，只要达到不同人员使用的功能不同即可。

数据权限可以控制组织、可以控制数据域（比如，10个门店，有的人能看到1个门店的数据，有的人能看到10个门店的数据）

做个比喻，功能权限就像是容器，觉得了你有什么功能，数据权限就像水，决定了你容器内放的是什么。功能权限和数据权限是相互独立的。

数据权限是指对系统用户进行数据资源的可见性、以及控制性。直白说：“复合条件的用户才能查看和操作对应数据的权限”

比如公司老板需要看到公司的营收、利润、用户增长数据

公司运营总监需要看到互联网产品业务营收

公司公司销售要看实物销售产品的以后

在数据权限设计下，要定义清楚规则元

名词定义：规则元。在本文是指单个独立的数据规则定义，不同用户对规则元可设置具体的规则过滤值，该值用作数据查询时的筛选条件。

规则元配置：规则元名称的配置。一个表中哪些字段可以进行规则设置，以及规则元名称如何与表字段关联。

我们常接触到的数据访问权限都通过组织机构去划分，在实际应用中，也可能会根据业务增加其他维度的访问权限，如终端门店管理中单独设置门店访问权限，企业多品牌营销中设置品牌访问权限等。

1、以机构层级向下覆盖

根据组织机构树设定用户默认拥有所属组织及以下的数据访问权限。也是最基础的一种数据权限，对于简单的

2、与角色融合的数据访问权限

在设定角色时，同时设置该角色对应功能权限下的的数据访问权限层级：本人、本部门、本部门及以下、全公司。

用户可视菜单中的数据权限由拥有该菜单的角色数据权限而定，且当一个用户拥有多个角色时，角色菜单有重叠的，取两角色中最大数据权限，或数据权限并集。

3、设置部门访问权限

用户默认拥有所属组织及下级组织的访问权限，同时可以自由配置其他部门的访问权限，使得某些数据可以跨部门查看。

相比常规的基于企业组织架构，权限向下覆盖的方式，采用部门访问权限配置可以根据业务需求灵活地配置用户的访问数据范围，避免了父、子、兄弟甚至其他节点间的数据共享纠结，实现跨部门数据共享。

将数据访问权限分配在用户上，足够灵活但也牺牲了维护便捷性，在用户特殊访问权限不多的情况下可以选择该类方法进行设置。

4、实际应用中根据业务需要划定数据及功能权限范围

在实际应用中，仅通过部门设置数据访问权限不一定能满足业务数据的分界要求，在具体的功能里往往通过部门访问权限+其他条件组合的情况来限制用户数据权限范围。

如【部门访问权限+角色标签】，公司内部有领导类的角色，某种业务的原始单据信息需要给高层领导类角色的查看权限，但涉及到管理分权又不想赋予该类人员所有部门访问权限，此时要么单独开入口查询所有信息，领导类角色功能权限中都配置上该页面，也可以在该页面查询数据时，在部门访问权限之前再加一层角色标签的判断逻辑，若角色标签为领导的则不需要根据部门访问权限过滤。

总结及碎碎念

B端系统权限设计中，系统权限区分为功能权限和数据权限，分别对应系统中的功能模块和系统中的数据，功能权限大多基于RBAC模型，并可根据业务需要引入角色继承、用户组、角色标签等概念，数据权限主要基于用户机构、角色，或单独在页面中根据实际需要进行配置。但最终，所有的设置都是需要基于业务，先有业务、需求后有产品，只是权限配置这一功能模块偏向于公司层面要求，受公司业务形态影响较小，所以能抽象出一套较广泛适用的系统方法。

基于角色的访问控制模型就是把“用户—角色—操作—资源”关联到一起，实现非自主型访问控制策略。使用基于角色的访问控制模型可以减轻安全管理工作，因为某种任务是稳定的，而负责该项任务的人员是经常变化的，这种方式只需把新的用户分配给已有的角色即可，无需为用户重新指定资源和操作，因而简化了授权管理工作。

为了保障本系统操作使用的信息安全，系统登录认证体系由三个要素组成:用户、角色、权限，三者相辅相成，共同组成系统的安全运行屏障。

1.用户信息

用户信息表统一管理，在用户信息表中存储用户名称、登录名、口令、各子系统权限、用户角色信息等。

用户信息表的添加、删除以及子系统权限修改由总系统授权的管理员执行，本系统中，用户信息表的操作在业务处理与信息服务子系统的系统管理菜单下的用户信息管理页面。用户口令可以自行改变，用户权限的变更需要提请管理员同意，并由管理员修改。

子系统启动时读取用户信息表验证用户权限，在系统运行时依据权限分配相应的功能。依据用户在子系统中的权限级别控制用户可操作的功能，实现最终用户对ORACLE数据库中数据的读取和添加操作权限控制(表8－2)。

表8－2 用户信息结构表

2.角色信息

角色可以根据需要任意多地添加，多个角色权限组合生成多个权限控制，对应到一个确定的用户，赋予用户对功能模块的控制权限。用户角色表包括角色名称、用户唯一值编码等信息。示例见表8－3。

表8－3 用户角色表(示例)

在数据库中为各个功能模块建立了功能名称表，每个功能模块均有记录，有功能编码和功能名称及其他附属信息。功能名称示例见表8－4。

表8－4 功能名称表(示例)

每个用户必须属于至少一个角色，每个角色具备多个功能的控制权限，功能权限通过角色传递给用户，从而实现用户对功能的操作权限控制。

3.权限信息

权限表明了用户可执行的操作。系统权限控制采用最大优先，用户可以拥有多个角色，每个角色对每一页面都可拥有权限，但在权限结果判断时只以最大权限为主，即管理员级权限大于并包含访问者权限。功能权限示例如表8－5所示。

表8－5 功能权限表(示例)

系统规划的子系统权限等级见表8－6。

表8－6 子系统权限等级规划表(部分)

续表

4.用户认证授权

通过以上四个表将用户、角色与权限组合起来，可以形成无穷多的用户权限组合，直接控制用户权限到每个细分功能。

用户、角色、权限、功能控制流程如图8－1所示:

图8－1 用户权限控制流程图

功能权限表仅在部署角色权限时使用，标示功能具备的可部署权限。

在角色中必须保证有一个管理角色拥有用户管理功能的管理权限，防止不能分配角色与权限，同样在用户中必须保证至少有一个用户是管理角色。