写这篇文章的缘由是，自己在搭建B端系统中设计权限管理时在网上查找了一些资料，发现大部分的文档是写给技术同学的。因此想写一篇产品视角的权限管理设计，便是下面这篇B端权限管理设计。
一，前情
杨堃老师在《决胜B端》一书中讲到，B端产品的细节设计包括界面设计、报表设计、数据埋点设计、权限设计等。将权限设计看作B端产品经理的基本功之一。目前使用较广泛的权限管理是RBAC方案，RBAC(Role-Based Access Control)基于角色的访问控制，是由莱威·桑度（Ravi Sandhu）等人在前人的理论基础上，于1996年提出的。又被称为RBAC96。
权限管理是解决系统中“谁可以看见什么并允许进行哪些操作”的问题。试想一个系统中所有员工都可以审批打款，都可见公司的营收，那还要领导做什么？老板还安不安心？但从产品的视角考虑，一个系统的权限管理搭建到什么程度才是最优解？对此，个人倾向于当系统的用户是十几个人时，直接为每个用户赋予权限即可；当系统的用户在几十到百人，直接管理个人权限会很繁琐，这时使用角色来批量管理权限会方便很多；而当系统的用户达到几百上千人甚至更多时，会频繁地有员工入职、离职，这时为了方便管理可以配置权限组，为某个部门、某种岗位的员工入职后默认开启某个角色。
二，RBAC模型
RBAC模型包含四种模型：RBAC0、RBAC1、RBAC2、RBAC3。其中RBAC0是基础，RBAC1、RBAC2是在RBAC0的基础上做了扩展。而RBAC3 = RBAC1 + RBAC2。
2.1 RBAC0
在RBAC0模型中，抽象出三个基本概念：用户、角色和权限，并通过
1. 定义角色的权限；
2. 给用户授权角色；
来控制用户的权限，实现了用户和权限在逻辑分离，方便权限的管理。其中，
a. 用户与角色、角色与权限之间均为多对多的关系。
b. 权限可以拆分为四类：
页面访问：eg, 财务同学不需要看到运营同学的操作页面；
按钮操作：eg, 运营同学可以创建/查看客户资料，但审核通过只能由运营主管操作；
字段权限：eg, 在eHR中员工的身份证号码、薪资等敏感数据，只能展示给特定的角色；
数据范围：eg, 区域采购员，他只能查看所在分公司的数据，而不能查看总公司数据；
在产品设计时，我们要考虑到为角色设置这四方面权限的能力。
2.2 RBAC1
考虑这样一个场景，某系统的地区负责人有此地区人员管理的权限，那么他在为本地员工分配权限时可以分配总公司管理员这一角色吗？答案当然是不行的。在RBAC0的模型中，这个问题不太好解决。为此，RBAC1在RBAC0基础上引入角色之间的上下级关系。使角色有了分组和分级，这样地区管理员在为本地员工分配角色时只能分配自身角色或者是自身角色的子角色，避免系统中权限的泛滥。
2.3 RBAC2
RBAC2是在RBAC0模型的基础上做了角色的约束控制，增加了责任分离关系，包括静态责任分离和动态责任分离。主要包括以下约束：
互斥角色: 同一用户只能分配到一组互斥角色集合中至多一个角色。比如财务部员工不能同时被分配会计和审核员两个角色；
基数约束: 一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；
先决条件角色: 用户想获得某上级角色,必须先获得其下一级的角色；
我在实际的系统设计中没用到过RBAC2，复制过来供大家参考。
2.4 权限组
在网上能查到的资料中对权限组的解释不统一，有的只是角色的另一个称呼。但在这里，我期望的权限组是系统自动为同一类用户赋予相同的角色。例如，某在线教育公司的辅导部有几千名的辅导老师，其中约一千人是兼职，流动频繁，若仅用角色管理，辅导部的管理者每天会花费不少时间在为新人分配角色上，做低效无用功。这种场景下就可以配置一个权限组，指定辅导部下的辅导老师在成功入职，人力系统推送该员工过来后自动开启辅导老师角色。这样，大多数人的权限将由系统默认配置，管理员只需要处理个例或异常情况。
三，产品设计
在角色管理中，因为角色有了上下层级关系，所以使用了树结构；
这里需要系统在初始化时就默认一个管理员，新建角色只能是这个角色的子角色。
在角色配置详情页，配置角色的四种权限，菜单权限、操作权限、字段权限、数据权限；
角色有了继承关系，因此子角色可配置的最大权限是父角色所拥有的权限；
此外，字段权限还可在细化为，不可见、仅可见、可编辑；
数据范围权限可根据业务背景做灵活设计。
在权限组管理上，我们为指定部门的指定职位配置角色，这里的部门和职位可以是多对多的；
四，后话
以上就是RBAC模型核心思想的简单介绍和应用，我们在实际设计产品中可根据业务模式或需求做灵活变动，如当用户角色相同但要求看到的数据差别很大时，可以将数据权限放到用户管理上设置等。另一方面，在做实际需求时也要更多地考虑边界情况和逆向流程，如：角色有子角色时是否允许删除？权限组删除对用户权限的影响等。
