权限系统设计

    几乎所有的管理后台都会涉及到权限的设计，权限控制是管理后台的重要功能，可以有效的提高系统的安全性，减少误操作、数据泄漏等风险的发生。但是，很多产品经理会对权限功能有一点害怕的心理，一方面是由于能参考的实例较少，权限管理算是一个“系统级”的基础功能，一般系统中只有管理员可以操作，不像其他功能可以通过去其他系统中试用体验，另一方面，对于权限功能普通用户无法操作使用，所以存在感较低，做好了也不会出彩，可没做好就会导致整个流程不通、产品崩溃。

一 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)

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模型是不变的,我们可以在其基础上进行扩展来满足需求。

权限管控可以通俗的理解为权力限制，即不同的人由于拥有不同权力，他所看到的、能使用的可能不一样。对应到一个应用系统，其实就是一个用户可能拥有不同的数据权限（看到的）和操作权限（使用的）。

Access Control List，ACL是最早的、最基本的一种访问控制机制，是基于客体进行控制的模型，在其他模型中也有ACL的身影。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式。

原理：每一个客体都有一个列表，列表中记录的是哪些主体可以对这个客体做哪些行为，非常简单。

例如：当用户A要对一篇文章进行编辑时，ACL会先检查一下文章编辑功能的控制列表中有没有用户A，有就可以编辑，无则不能编辑。再例如：不同等级的会员在产品中可使用的功能范围不同。

缺点：当主体的数量较多时，配置和维护工作就会成本大、易出错。

Discretionary Access Control，DAC是ACL的一种拓展。

原理：在ACL模型的基础上，允许主体可以将自己拥有的权限自主地授予其他主体，所以权限可以任意传递。

例如：常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。

缺点：对权限控制比较分散，例如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大，无意间就可能泄露信息。

Mandatory Access Control，MAC模型中主要的是双向验证机制。常见于机密机构或者其他等级观念强烈的行业，如军用和市政安全领域的软件。

原理：主体有一个权限标识，客体也有一个权限标识，而主体能否对该客体进行操作取决于双方的权限标识的关系。

例如：将军分为上将>中将>少将，军事文件保密等级分为绝密>机密>秘密，规定不同军衔仅能访问不同保密等级的文件，如少将只能访问秘密文件；当某一账号访问某一文件时，系统会验证账号的军衔，也验证文件的保密等级，当军衔和保密等级相对应时才可以访问。

缺点：控制太严格，实现工作量大，缺乏灵活性。

(Attribute-Based Access Control)，能很好地解决RBAC的缺点，在新增资源时容易维护。

原理：通过动态计算一个或一组属性是否满足某种机制来授权，是一种很灵活的权限模型，可以按需实现不同颗粒度的权限控制。

属性通常有四类：

例如：早上9:00 11:00期间A、B两个部门一起以考生的身份考试，下午14:00 17:00期间A、B两个部门相互阅卷。

缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用的很少。

RBAC的核心在于用户只和角色关联，而角色代表对了权限，是一系列权限的集合。

RBAC三要素：

在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。

RBAC模型可以分为：RBAC 0、RBAC 1、RBAC 2、RBAC 3 四个阶段，一般公司使用RBAC0的模型就可以。另外，RBAC 0相当于底层逻辑，后三者都是在RBAC 0模型上的拔高。

我先简单介绍下这四个RBAC模型：

RBAC 0模型： 用户和角色、角色和权限多对多关系。

简单来说就是一个用户拥有多个角色，一个角色可以被多个用户拥有，这是用户和角色的多对多关系；同样的，角色和权限也是如此。

RBAC 0模型如下图：没有画太多线，但是已经能够看出多对多关系。

RBAC 1模型： 相对于RBAC 0模型，增加了角色分级的逻辑，类似于树形结构，下一节点继承上一节点的所有权限，如role1根节点下有role1.1和role1.2两个子节点。

角色分级的逻辑可以有效的规范角色创建（主要得益于权限继承逻辑），我之前做过BD工具（类CRM），BD之间就有分级（经理、主管、专员），如果采用RBAC 0模型做权限系统，我可能需要为经理、主管、专员分别创建一个角色（角色之间权限无继承性），极有可能出现一个问题，由于权限配置错误，主管拥有经理都没有权限。

而RBAC 1模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持针对性删减主管权限。

RBAC 1模型如下图：多对多关系仍旧没有改变，只增加角色分级逻辑。

[图片上传中...(-95cc0-1640060170347-0)]

RBAC 2模型： 基于RBAC 0模型，对角色增加了更多约束条件。

如角色互斥，比较经典的案例是财务系统中出纳不得兼管稽核，那么在赋予财务系统操作人员角色时，同一个操作员不能同时拥有出纳和稽核两个角色。

如角色数量限制，例如：一个角色专门为公司CEO创建的，最后发现公司有10个人拥有CEO角色，一个公司有10个CEO？

这就是对角色数量的限制，它指的是有多少用户能拥有这个角色。

RBAC 2 模型主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。

RBAC 3模型： 同样是基于RBAC0模型，但是综合了RBAC 1和RBAC 2的所有特点。这里就不在多描述，读者返回去看RBAC 1和RBAC 2模型的描述即可。

RBAC 权限模型由三大部分构成，即用户管理、角色管理、权限管理。用户管理按照企业架构或业务线架构来划分，这些结构本身比较清晰，扩展性和可读性都非常好。角色管理一定要在深入理解业务逻辑后再来设计，一般使用各部门真实的角色作为基础，再根据业务逻辑进行扩展。权限管理是前两种管理的再加固，做太细容易太碎片，做太粗又不够安全，这里我们需要根据经验和实际情况来设计。

用户管理中的用户，是企业里每一位员工，他们本身就有自己的组织架构，我们可以直接使用企业部门架构或者业务线架构来作为线索，构建用户管理系统。

需要特殊注意：

实际业务中的组织架构可能与企业部门架构、业务线架构不同，需要考虑数据共享机制，一般的做法为授权某个人、某个角色组共享某个组织层级的某个对象组数据。

在设计系统角色时，我们应该深入理解公司架构、业务架构后，再根据需求设计角色及角色内的等级。一般角色相对于用户来说是固定不变的，每个角色都有自己明确的权限和限制，这些权限在系统设计之处就确定了，之后也轻易不会再变动。

（1）自动获得基础角色

当员工入职到某部门时，该名员工的账号应该自动被加入该部门对应的基础角色中，并拥有对应的基础权限。这种操作是为了保证系统安全的前提下，减少了管理员大量手动操作。使新入职员工能快速使用系统，提高工作效率。

（2）临时角色与失效时间

公司业务有时需要外援来支持，他们并不属于公司员工，也只是在某个时段在公司做支持。此时我们需要设置临时角色，来应对这种可能跨多部门协作的临时员工。

如果公司安全级别较高，此类账号默认有固定失效时间，到达失效时间需再次审核才能重新开启。避免临时账号因为流程不完善，遗忘在系统中，引起安全隐患。

（3）虚拟角色

部门角色中的等级，可以授权同等级的员工拥有相同的权限，但某些员工因工作原因，需要调用角色等级之外的权限，相同等级不同员工需要使用的权限还不相同。这种超出角色等级又合理的权限授予，我们可以设置虚拟角色。这一虚拟角色可集成这一工作所需的所有权限，然后将它赋予具体的员工即可。这样即不用调整组织架构和对应的角色，也可以满足工作中特殊情况的权限需求。

（4）黑白名单

白名单：某些用户自身不拥有某部门的顶级角色，但处于业务需求，需要给他角色外的高级权限，那么我们可以设计限制范围的白名单，将需要的用户添加进去即可。在安全流程中，我们仅需要对白名单设计安全流程，即可审核在白名单中的特殊用户，做到监控拥有特殊权限的用户，减少安全隐患。

黑名单：比较常见的黑名单场景是某些犯了错误的员工，虽然在职，但已经不能给他们任何公司权限了。这种既不能取消角色关联，也不能完全停用账号的情况，可以设置黑名单，让此类用户可以登录账号，查看基本信息，但大多数关键权限已经被黑名单限制。

权限管理一般从三个方面来做限制。页面/菜单权限，操作权限，数据权限。

（1）页面/菜单权限

对于没有权限操作的用户，直接隐藏对应的页面入口或菜单选项。这种方法简单快捷直接，对于一些安全不太敏感的权限，使用这种方式非常高效。

（2）操作权限

操作权限通常是指对同一组数据，不同的用户是否可以增删改查。对某些用户来说是只读浏览数据，对某些用户来说是可编辑的数据。

（3）数据权限

对于安全需求高的权限管理，仅从前端限制隐藏菜单，隐藏编辑按钮是不够的，还需要在数接口上做限制。如果用户试图通过非法手段编辑不属于自己权限下的数据，服务器端会识别、记录并限制访问。

数据权限如何管控

数据权限可以分为行权限和列权限。行权限控制：看多少条数据。列权限控制：看一条数据的多少个字段

简单系统中可以通过组织架构来管控行权限，按照角色来配置列权限，但是遇到复杂情况，组织架构是承载不了复杂行权限管控，角色也更不能承载列的特殊化展示。

目前行业的做法是提供行列级数据权规则配置，把规则当成类似权限点配置赋予某个角色或者某个用户。

网易有数做法：

https://youdata.163.com/index/manual/o/6System_management/data_role.html

1.超级管理员

超级管理员是用来启动系统，配置系统的账号。这个账号应该在配置好系统，创建管理员之后被隐藏起来。超级管理员账号拥有系统中全部权限，可穿梭查看各部门数据，如果使用不恰当，是系统管理的安全隐患。

2.互斥角色如何处理

当用户已经有用的角色和即将添加的角色互相互斥时，应该在添加新角色时，提示管理员因角色互斥的原因，无法进行新角色添加。如需添加，要先撤销掉前一个角色，再添加新角色。

3.用户管理权限系统设计一定要简单清晰

在设计权限系统之处，一定要理清思路，一切从简，能不增加的多余角色和权限逻辑，就一定不要增加。因为随着公司业务的扩大，权限和角色也会随之增多，如果初期设计思路不严谨，那么权限系统会随着业务的扩大而无限混乱下去，此时再来整理权限，已经太晚了。所以初期设计就一定要条理清晰，简单明了，能避免后续非常多不必要的麻烦。

4.无权提示页

有时员工 A 会直接给员工 B 分享他当下正在操作的页面，但有可能员工 B 无权查看。此时我们应该在这里考虑添加「无权提示页」，避免粗暴的 404 页面让员工 B 以为是系统出错了。

在一套后台管理系统中，系统通常会有多种需求的用户登陆。例如系统维护人员、运营分析人员、文案编辑人员、部门管理人员等等，而系统维护人员登陆要看到日志界面和服务器监控界面，文案编辑人员要看到文章界面等等，不同的用户登陆到后台还需要展示不同的菜单和界面，

单单运营分析人员，在系统中可以可能有A分公司运营助理、B分公司运营主管、C部门运营经理、华东大区运营总监等等类型，A分公司的运营助理只能看A公司的运营数据，C部门运营经理只能看到C部门的运营数据，大区运营总监应该要看到属于华东大区的所有公司以及部门的数据，不同人员能够查看的数据范围应该是不同的

其次，上述提到的的文案编辑人员，还会区分出总编辑，和文案撰稿人，虽然同样能看到文章管理界面，但总编辑拥有添加、编辑、删除、审核、发布等功能，普通文案只有有添加、修改的权限。

本文将对上述提到的场景提出一种基础的解决方案。

【 角色】： 系统运维、运营分析、部门职员这类拥有不同权限功能的标签，我们称之为“ 角色” 。

【 组织部门】： A分公司、C部门、华东大区、无论大小我们统称为“ 组织部门” 。

【岗位】： 运营助理、运营主管、运营经理、运营总监我们统称为“ 岗位” 。

【 数据权限】： 大区运营和部门运营所能看到的数据范围不同，我们称之为“ 数据权限”。

【 资源权限】： 文章管理撰稿人比总编辑少了审核、发布的功能，这些功能我们称之为“ 资源权限” 。

有了角色，部门组织，岗位，数据权限，资源权限这5个概念的结合就可以结合出满足一般使用场景的权限设计。

      我们将数据权限、资源权限接关联在一个角色上，然后将关联好的角色与用户绑定，这样就完成了权限对用户的分配。另外，我们也可以将角色关联在某个部门的岗位上，然后用户只要填写所属部门和岗位即可获得权限。

     比如文案总编辑、撰稿人、审稿人、编辑助理这类有特定的功能职能的用户群体，我们能就可以创建成角色。但要注意的是，角色一般是可以多个同时并存的。比如创建一个新文案负责人，组织允许他既可以自己撰稿，也可以帮助别人审稿，这时候往往不会在当独为他设计一个撰稿审稿人角色，而是同时为他分配撰稿人+审稿人两个角色。这样，该用户的权限就变成了他所有角色关联的权限之和。从而减少因为权限的交叉带来的冗余角色。

    岗位和角色的概念其实是挺相似的，一个岗位一定程度上代表了他在组织中的角色。然而同样的岗位在不同的组织部很可能是不同的：   例如A部门的采购主管和B部门的采购主管。同样是主管的岗位，但A采购公司规定可以查看整个部门数据、不允许查看订单，而B采购可以查看订单数据、但不允许查看部门其他采购主管的数据，从而造成了同岗不同权。

    这时，我们可以单独为这些部门各自创建岗位，并将角色组直接关联在各自的岗位上。例如在A分公司中分配一个岗位叫做采购主管， 然后我们为这个岗位预设好 “采购数据分析员”，“采购数据录入员”，“订单审核人员”的角色。 这样以来，当A公司来了一位新的采购主管，我们只要为他创建好账号，然后为他设置这个岗位就可以实现权限的绑定。

    撰稿人可以编写文章，审稿人只能查看和标记审核结果，区分两者权限不同，依靠的就是资源权限的不同。我们可以在撰稿人角色上绑定“文章:编辑、文章:查看、文章:添加”这三个资源权限，为审稿人角色绑定“文章:查看、文章:审核”两个资源权限，然后在系统中判断用户的权限来控制相应的入口显示。例如判断用户的权限中不包括“文章:审核”权限，页面就隐藏掉审核的开关按钮。

    数据权限我们目前只分三种，“仅自己数据”，“部门数据”，“全部数据”。如字面含义一样，“仅自己数据”只能查看与自己直接关联的数据，比如自己的销售额，自己的考勤记录。“部门数据”允许用户看到整个部门乃至下级部门的所有成员的数据，比如整个部门的销售额，部门中某个用户的考勤记录。“全部数据”属于最高级别的数据权限，一般是平台的总公司总经理、或者某个系统的总负责人可以使用的到。需要注意的是，数据权限需要结合“资源权限“以及下面将提到的“组织部门“一起组合使用才能发挥效果。

   组织部门可以区分用户在系统中的不同组织、不同等级关系。比如一个平台往往可以接入众多的公司，如图

组织与组织之间有明显的层级架构关系，结合数据权限、资源权限、角色、岗位、就可以灵活配置出例如图中销售部门A的销售经理权限，以及销售团队1的队长权限等等。

上述的结构只是一种方案，当然方案不可能是万能的，具体的实现还需要结合实际项目需求进行设计开发。

角色：特定权限的集合； 

权限：角色可使用的功能，分角色的功能权限和角色的数据权限；

RBAC设计方案：基于角色的权限设计方案,更好的管理用户；

操作类型：对资源可能的访问方法，如增加、删除、修改等； 

 功能：对资源的操作，是资源与操作类型的二元组，如增加销售单、修改销售单等；

 资源：系统中的资源，主要是各种业务对象，如销售单、付款单等； 数据类型：业务系统中常用的数据权限类型，如公司、部门、项目、个人等；

 数据对象：具体的业务对象，如甲公司、乙部门等等，包括所有涉及到数据权限的对象值；权限设计原则：第一：权限的粒度要做到最小，保证在权限分配时，只赋予用户足够完成其工作的权限；第二：避免出现权限互斥的情况

权限设计原则：第一：权限的粒度要做到最小，保证在权限分配时，只赋予用户足够完成其工作的权限；第二：避免出现权限互斥的情况；

所以基于数据的权限设计（数据权限则是控制你可以看到哪些数据，比如市场A部的人只能看到或者修改A部创建的数据，他看不到或者不能修改B部的数据。）

第一步梳理：梳理层级关系（我们可以找出每一个层级的BOSS）

超级管理员：

集团管理员

城市管理员（我们也可对这个城市组织节点授权）

学校管理员（我们也可对学校组织节点授权）

部门管理员（我们也对对这个部门组织节点授权）

 第二步：每一层建立角色

每个后台用户可以自定义角色，给相应的用户授权，每个后台用户的权限是上一个后台用户权限的子集，后台用户创立角色的权限是子集的权限子集；这里也可以首先给城市，学校，部门这个组织节点分配权限，当每一层的管理员建立角色分配权限时只能是这个城市权限的子集；

第三步：给角色授权

     这里我要将所有的权限进行打散：系统功能的筛选无非是从：系统名称-模块名称-功能项（这里的功能项已经拆解到按钮级别了）

第四步：给用户授权

 角色创立了，我们就可以对用户进行授权，角色和用户的关系可以是一对一，也可以是一对多的关系；

总结：

     以上就是本人对如何做权限设计的总结分析，仅供大家参考，希望在工作中能够帮助到大家，也希望大家一起多提意见，指出不足，感谢阅读！

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

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

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

最高权限角色

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

副管理员角色

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

部分权限所有者角色

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

特约用户角色

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

付费用户角色

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

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

▲   角色之间关系  

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

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

▲   RABC角色权限  

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

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

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

▲   部门管理  

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

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

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

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

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

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

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

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

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

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

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

2.添加/创建用户

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

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

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

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

▲   系统权限创建流程

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

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

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

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

▲   

数据权限的设计

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

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

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

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

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

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

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

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

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

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