权限管理那些事儿

我在做教育产品之前做过一段时间的OA，其实相比于做教育，我个人更喜欢做OA产品，除了做出来的东西能够大概率被公司的同事和身边的人用到从而能够及时收到反馈之外，OA产品更加具有逻辑性、更讲究权责划分，产品基调更加理性也是其中的一个原因。那么讲到权责划分，就不得不提几乎所有OA类产品都会涉及到的权限管理。

其实不仅仅是OA产品，几乎所有的B端产品，甚至包括很多的C端产品都会涉及到权限管理，我还记得自己在第一次接触权限管理的需求的时候，一脑子浆糊的情形。碰巧最近又有涉及到权限管理的需求，所以将自己对权限管理粗浅的理解写一下，希望能够对阅读这篇文章的你有所帮助。

什么是权限管理

首先什么是权限？权限通俗的来讲，就是在某个组织中，某个或者某些人，可以对某件事进行决策、执行的范围或者程度，如果这个人具有这样的特征，我们往往将他描述为他具有这样 的权限。由此及彼，权限管理，就是对权限进行管控，限制和分配不同的人拥有不同的的权限。

二、为什么要有权限管理

古人云：没有规矩不成方圆。权限管理就是“规矩”的一种，它限制人们做事的范围，保证相互之间不会产生冲突，又能使得系统有序的运行而不产生错误。这种思想体现在我们生活的方方面面。

对于一个人而言，人体的每个器官都有自己的“权限”，舌头不会做肝脏解毒的工作，而胃也不做牙齿咀嚼的事情，每个器官各司其职，而他们的运作又会听从大脑这个“超级管理员”的指挥，从而能够让人体保持有序的运转。

同样，对于企业而言，对公司员工进行权限分配，也是为了使公司的管理更加有序而高效：

• 能够保证员工各司其职，每人所负责的内容不同，互不干扰，从而提高工作效率；
• 每人负责的工作范围具体而明确，责任到人，权责分明，出了问题有据可查；
• 不同的人负责的工作重要度有高有低，如机密或者重要决策能够只被少数人知晓，能够保证隐私从而规避风险。

三、权限管理的利器：RBAC模型

谈到权限管理就不得不提到RBAC模型，这是目前大部分涉及到权限管理的产品都会使用的一种模型。RBAC，英文全称Role-Based Access Control，基于角色的权限访问控制，它将who、what、how进行了关联，解释了谁（who）对什么（what）做了怎么样操作（how）的问题。

RBAC包含了四个子模型，分别是RBAC0，RBAC1，RBAC2和RBAC3，它们的核心思想都是相同的，只是在某些地方有差异，下面会进行具体的介绍它们的各自的特点。

RBAC0

RBAC0是整个RBAC模型中的基础，后面RBAC1，RBAC2、RBAC3都是由它演化而来，在它的基础上进行各自的变形。RBAC0最显著的特点就是人不直接与权限相关联，而是通过角色这一中间介质，获取系统的权限。

说句题外话，为什么不直接将权限分配给用户，而非要借助角色来进行权限分配呢？以一家公司来举例：

• 首先人员数量大，如果一个个去分配人的权限，工作量无疑是庞大的；
• 每一个新入职的员工都需要为他配置权限，同样，员工离职后，也需要解除他的权限并将该权限重新分配到另一个负责人，操作麻烦；
• 每当公司人员权限变动，如今天取消部门经理请假表单的审批权限，过两天要增加部门经理报销单据的审批权限，那么需要对全公司的经理进行权限调整，非常不灵活；

因此在实际操作中，我们往往不将权限与用户直接挂钩。

那么RBAC0中的用户、角色与权限的关系到底是怎么样的呢？我们用一张图来解释。

可以看出用户和角色之间属于多对多的关系：用户1可以同时拥有角色1，角色2和角色3多个角色，同时角色1又可以同时归属于用户1和用户2 多个用户；

• **角色与权限之间属于多对多的关系：**角色1可以同时拥有权限1，权限2和权限3多个权限，同时权限1又可以被分配给角色1、角色2和角色3多个角色；
• 用户所拥有的权限等于他所拥有的所有角色下的权限的总和；

以一个具体的案例来进行进一步说明：

在公司内，我们会根据员工的职级不同，创造不同的角色，如CEO、总监、经理、主管、小组长、职员等，我们只需要对这些角色分配不同的权限，再将这些角色赋予一个或一批人，就可以实现灵活的管理公司职工的权限。如只有CEO才能查看员工薪资，那么只需要将员工薪资查看的权限分配给CEO即可。又比如王小明既是开发部门的经理，又是测试部门的经理，那么就可以直接将两个部门的经理角色赋予王小明，就可以让王小明同时具有两个部门的经理权限。

RBAC1【这个数据库不知道怎么设计，需要思考下】

RBAC1是在RBAC0的基础上，增加了角色分层和角色继承的能力。角色分层简单来说，就是一个角色可以拥有不同的等级 ，不同的等级也会拥有不同的权限。而角色继承则是指，如果用户1和用户2同属于一个角色，当用户1离职或者工作调动，则可以将其权限原封不动的继承给用户2，使用户2具有用户1的所有权限。

• 一个角色可以拥有多个等级，角色和等级之间是一对多的关系；
• 一个角色下的不同等级之间，具有相同的权限，但又会有不同的权限，但他们都只会拥有该角色下的权限。???

通过角色分级，可以实现更加精细化的权限分配，还是以上面的那个例子来说明：

王小明是公司的开发部门的经理，具有公司开发人员的的管理权。而王小亮是副经理，只具有部分管理权。此时我们就可以设置一个比经理低一等级的副经理的角色，并赋予该角色部分经理的角色即可。当有一天王小明离职了，王小亮被提拔成经理，那么可以直接将王小明的角色继承给王小亮即可。

RBAC2

RBAC2是在RBAC0的基础上增加了对角色和权限的一些限制。

• 角色互斥限制。限制当系统中有多个角色时，用户只能同时拥有它们中的一个角色。或者当用户拥有多个角色时，只能同时激活使用其中的一个角色。
• 角色基数限制。限制用户只能同时拥有或激活的一定数量的角色，或者限制角色只能被赋予一定数量的权限。
• 先决条件限制。当用户想要拥有一个角色时，必须现拥有另一个角色才可以，或者当角色需要拥有一个权限时，必须先拥有另一个权限。

还是以上面的案例来说明：

小明拥有公司的开发部门经理的角色，此时就不会再让他拥有公司财务部门的经理角色，否则他自己既可以审批报销单据，又能进行报销金额的发放，容易出现贪污现象。这就是角色互斥限制。

比如王小明拥有开发部门经理的角色，同时又具有测试部门经理的角色，公司规定一个人最多能担任两个岗位，因此他无法再成为产品部门的经理。这就是角色基数限制。

又比如王小明想要升级为公司的CEO，那么按照公司的规定，他必须先成为公司的技术总监之后，才能进一步升职为CEO。这就是先决条件限制。

RBAC3

RBAC3其实是RBAC1和RBAC2的合集，也就是它同时具有RBAC1和RBAC2这两个模型的所有特点。我们用一张图来描述一下他们之间的关系：

在RBAC0是基础，在此之上，分别延伸出的RBAC1和RBAC2，它们具有RBAC0的特点，同时又各自拥有自己的特点。而RBAC3则同时拥有RBAC1和RBAC2的所有特点。

四、模型拓展

1.用户与用户组

实际场景中，我们除了对上述模型中对用户的角色或者权限进行管理以外 ，我们还可以对用户进行管理，将不同的用户归纳进用户组，并对用户组分配角色，这样该用户组下的所有用户在拥有各自角色的权限外，还会具有该用户组角色的权限。

还是以王小明来举例。王小明作为开发部门的经理，具有管理的权限，同时他也在开发这一用户组下，因此他也可以进行代码的提交。

2.权限和权限组

权限组其实也是在RBAC模型的基础上演变而来的。是指将系统中的权限进行归纳，形成一个集合，在对角色分配权限的时候，直接将该权限组分配给对应的角色即可，而不用频繁多次的开通对应的权限。

五、其他

• 我们在设计权限管理时，一般会将功能和数据进行抽象，分别进行管理。如设计员工个人档案时，会要求部分角色仅有查看的权限，另一部分角色既可以查看该页面，也可以对该页面进行编辑，查看和编辑就是对应着数据和功能的权限。
• RBAC3模型是上述能力最全面的模型，但不代表所有的权限设计都可以直接使用该模型，还是要根据业务的实际需求来决定，毕竟杀鸡不用宰牛刀。
• 权限管理无论如何变化，其核心思想都是不变的，即用户不再直接与单一权限进行挂钩，而是通过中间介质角色或者角色组等，将权限赋予对应的用户。
• 实际设计中，我们不能按照上述模型进行套用，而是需要理解不同模型各自的特点，并结合自身的业务要求，在RBAC模型的基础上进行一定的取舍（如上述用户组、权限组的变化），灵活的运用权限管理模型。