做B端产品，权限是无法躲过的一类问题。比如，企业类软件，不同部门、不同职位的人的权限是不同的；再例如，一款软件，不同付费层级的用户，所使用的权限也是迥然不同的。
一、权限
1.什么是权限
权限是基于实际业务的需要，设计的一套系统使用关系。没有固定的方法，每个公司可能都是不一样的。权限分为：页面权限、操作权限、数据权限。
页面权限：谁可以访问页面。例如，财务可以访问财务报表，而销售不可访问财务报表页面；
操作权限：谁可以操作数据。例如：老板和财务都可以访问财务报表，但是财务可以增删查改，但是老板只能看，不可以改；
数据权限：谁可以看哪个范围的数据。例如：销售一分部的老板只能看销售一分部的数据，公司的老板可以看整个公司的数据；
2.遇到的问题
网上很多关于RBAC的资料，大多与如何用数据表实现RBCA相关游戏动态，并不容易理解。很多人看了很多文章来描述权限、RBAC等等，看了很多rbac角色权限表设计，还是搞不清楚权限和RBAC的关系；或者看了RBAC也不知道如何去使用；在实际设计中，往往根据自我感觉就搭建了用户和权限模型。自己想的模型可能会导致很多问题，例如权限管理不够灵活，权限覆盖能力弱，甚至操作混乱等。
3.解决方法
实际上，已经有成熟的RBAC模型可直接应用于权限设计，我们无需自己拍脑袋设置用户权限模型，正如牛顿所言，站在巨人的肩膀上才能看的更远。我们不妨去参照已有的比较成熟的权限模型RBAC（Role-Based Access Control）——基于角色的访问控制。我会以产品经理的角度去解析RBAC模型，并分别举例如何运用这套已得到验证的成熟模型。
二、RBAC模型
1.传统权限模型
在没有RBAC前，传统权限模型通过账号直接配置权限。每一个账号都需要勾选账号对应的每一个权限，如下图。可见非常繁琐，维护起来非常麻烦。
2.RBAC概念
RBAC增加了“角色”的概念，我们首先把权限赋予角色，再把角色赋予用户。这样，由于增加了角色，授权会更加灵活方便。在RBAC中，根据权限的复杂程度，又可分为RBAC0、RBAC1、RBAC2、RBAC3，RBAC4。其中，RBAC0是基础，RBAC1、RBAC2、RBAC3、RBAC4都是以RBAC0为基础的升级。我们可以根据自家产品权限的复杂程度，选取适合的权限模型。
3.RBAC0：基本模型
解析：RBAC0是RBAC模型中最基本的模型，很多产品只需基于RBAC0就可以搭建权限模型了。用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。
举例：譬如我们做一款企业管理产品，如果按传统权限模型，给每一个用户赋予权限则会非常麻烦，并且做不到批量修改用户权限。这时候，可以抽象出几个角色，譬如销售经理、财务经理、市场经理等，然后把权限分配给这些角色，再把角色赋予用户。这样无论是分配权限还是以后的修改权限，只需要修改用户和角色的关系，或角色和权限的关系即可，更加灵活方便。此外，如果一个用户有多个角色，譬如王先生既负责销售部也负责市场部，那么可以给王先生赋予两个角色，即销售经理+市场经理，这样他就拥有这两个角色的所有权限。
4.RABC1：用户组/权限组模型
解析：在RABC0的基础上，加入了用户组的概念。账号既可以通过角色来配置权限，也可以通过用户组来配置权限。这样做的好处是，若存在多个角色具有统一的权限，无需对每一个角色的共同权限进行配置。仅需将共同权限配置在用户组，使账号归属于用户组即可；（此级别，也可同时存在权限组，类似于用户组，这里就不细讲了）
一个账号可以既存在用户组也存在角色，权限范围为其的并集；
举例：会计、出纳、公司老板均可以查看公司的财务报表，但是操作不同，会计审核，出纳付款，老板仅查看；此时只需要抽象出一个报表查看用户组，用户组配置所需查看的报表，再将会计、出纳、公司老板都加入用户组；这样，加入用户组的用户都可以查看报表；再将会计和出纳角色配置单独的操作权限，一并赋予，这样会计和出纳就既拥有了用户组的权限（可查看报表）3D角色，以及独特的操作权限（审核/付款）
5.RBAC2：角色继承模型
解析：角色继承，讲一个角色分为多个级别，高级别的角色可继承低级别角色的权限，上层角色继承下层角色的全部权限，且可额外赋予权限。
举例：
基于之前RBAC0的例子，我们又发现一个公司的财务经理可能是分三个等级的，财务经理、财务组长、财务员工。财务组长只有财务经理的部分权限。这时候，我们就可以采用RBAC1的分级模型，把财务这个角色分成多个等级，给财务组长赋予较低的等级即可。
6.RBAC3：角色限制模型
解析：角色限制的RBAC模型，指的是当用户可以存在多个角色时，多个角色质检存在限制条件。例如，一个人不能既是裁判rbac角色权限表设计，又是运动员；这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。
举例：
基于之前RBAC0的例子，我们又发现有些角色之间是需要互斥的，譬如给一个用户分配了财务经理的角色，就不能给他再赋予审计经理的角色了，否则他即可以录入账单又能自己审核账单；再譬如，有些公司对角色的升级十分看重，一个财务员工要想升级到财务经理，必须先升级到财务主管，这时候就要采用先决条件限制了。
7.RBAC4：统一模型
RBAC4是RBAC2和RBAC3的合集，所以RBAC3既有角色分层，也包括可以增加各种限制。
举例：
这个就不举例了，统一模型RBAC3可以解决上面三个例子的所有问题。当然，只有在系统对权限要求非常复杂时，才考虑使用此权限模型。
8.扩展案例
①公司架构如图，共有三种职能：前沿销售、前台、销售、老板，各职能角色分别如上图。前沿销售需要查看和操作客户列表、订单列表，销售需要查看和操作客户列表、订单列表，前台需要查看和操作客户列表，老板需查看所有的页面，但不可操作。
②权限说明：
1.页面权限：前沿销售——客户列表、订单列表；销售员工——客户列表、订单列表；销售主管——客户列表、订单列表、销售报表；前台——客户列表；老板——所有页面；
2.操作权限：前沿销售——客户列表（新增、删除）、订单列表（新增）；销售员工——客户列表（新增、删除）、订单列表（新增）；销售主管——客户列表（新增、删除）、订单列表（新增）、销售报表（导出）；前台——客户列表（新增）；老板——所有页面（无）；
3.数据权限：前沿销售——客户列表（本人）、订单列表（本人）；销售员工——客户列表（本人）、订单列表（本人）；销售主管——客户列表（本人及本人下属）、订单列表（本人及本人下属）、销售报表（本人及本人下属）；前台——客户列表（本人）；老板——所有页面（全部）；
③运用RBAC0
1.页面&操作权限：新建角色，勾选对应的页面以及操作
2.数据权限：新建数据权限，勾选对应查看数据的范围
但此时不要忘记，系统当前对账号之间的关系并不清楚，也就是系统并不知道账号的上下级关系；所以数据权限还需要搭配部门上下级的功能。
这样系统就知道，账号所处的部门，也就可以配置销售主管查看下属的数据了，如下；
此时，该账号已具备，1.查看本人及下属的数据权限 2.查看客户列表、操作客户列表的功能
9.最后的话
无论是本次的权限模型，还是其他产品相关实现方案，很多都已经被前人所总结提炼，我们应深度掌握这些成熟的知识和经验，而不是绞尽脑汁自我推理。我们只需要使用轮子，不需要自己创造轮子。（本文部分借鉴其他文章，如有雷同，是我抄你【偷懒了，还请谅解】）
