本文整理了常见的权限管理模型，根据自身项目经验总结说明了为什么要做权限管理、如何根据不同的组织管理形式进行不同的权限管理。

---

1、为什么B端要做权限管理

B端产品往往服务于企业。不管是大型的跨国企业，还是小微型的作坊型企业，都会建立适合其业务形态的组织机构进行管理。

对于B端系统而言，往往需要承载企业的客户数据、生产数据、业务数据和管理数据等，这些数据如果人人都能看、都能操作，那就会出大问题。

在实际工作中，领导和员工在系统中能够看到和操作的数据必然不同，不同部门的员工之间能看到和操作的数据也必然不同。但有些情况下，需要跨部门协同处理事务，不同部门又需要对相同的数据进行操作。这种情况下，权限管理就尤为重要。

权限管理的意义在于，给不同的用户分配合适的权限，用户各司其职，保证公司的业务能够正常流转。

例如，下图为典型的销售型企业的组织架构图。下文的说明均以此组织结构为例。

2、厘清概念

用户

实际使用系统的人。

例如销售分公司一的员工张三。

账号

用户在系统里的唯一ID，用户与账号可以是一对一或者一对多的关系。

例如，张三的账号为zhangsan。

角色

抽象出的一组功能权限的集合，不隶属于具体的部门。

例如销售分公司一的员工张三和销售分公司二的员工赵四，职位都是销售，日常的工作流程通过规范化管理，在系统中具备相同的功能权限，那么我们就可以抽象出“销售”这个角色赋予他们。

权限

用户可以访问的资源。权限可以分为三种颗粒度：页面权限、数据权限、操作权限。

页面权限是指可以查看哪个页面。例如张三是销售分公司一的普通销售，他就不应该看到财务审计的相关页面；

数据权限是指可以看到哪些数据。例如张三隶属销售分公司一，他就不应该查看销售分公司二的数据；

操作权限是指对页面上的按钮或者字段操作的权限，比如常见的增删改查、启动、终止等页面上的操作按钮。例如张三只能查看客户的授信情况，却无法进行编辑、删除等操作。

岗位

岗位是实际工作中的职位在系统中的抽象表达，可以理解成角色与组织机构和数据权限的集合。

例如王一的实际职位是运营总监，具有销售、运营多个角色，可以查看本部门及下级部门的数据。那么我们可以抽象出“运营总监”这个岗位，一个萝卜一个坑，今天是王一，明天王一离职，我们把这个岗位赋予新入职的用户即可。

3、常见的权限模型

3.1 传统的两层权限模型

传统的权限模型只有两层结构，对用户直接分配权限。

这种方式只适用于极少量用户、而且用户权限变动不频繁的系统。由于其局限性，现在已经逐渐淡出人们的视野。

3.2 RBAC模型

RBAC模型全称Role-Based Access Control，即基于角色的权限访问控制，最早由Ravi Sandu教授提出，后经过多次补充完善，形成了RBAC0、RBAC1、RBAC2、RBAC3四种逐步递进的权限模型。

RBAC由于其灵活性、可拓展性，得到了广泛的应用，现在大多数系统使用的权限管理均是在此基础上演变而来。

四种模型的关系如下图所示：

RBAC0为基础的RBAC模型，RBAC1在RBAC0的基础上引入了角色继承，RBAC2在RBAC0的基础上增加了限制，RBAC3是RBAC1和RBAC2的合集。

RBAC系列模型提出的个基本原则也是现在大多数系统的权限管理原则：

1）权限抽象：尽管所有的功能均可读写，但是功能本身是不同的

2）管理分离：将用户-角色分配和角色-权限分配分离

3）角色是权限的集合，与用户是多对多关系

RBAC0模型

是RBAC系统的基础，很多系统基于RBAC0就可以实现基本的权限管理需求。

RBAC0模型是将权限赋予角色、将角色赋予用户。用户、角色、权限之间都是多对多的关系。

RBAC1模型

在RBAC0模型的基础上引入了角色继承的概念，在系统中抽象反应组织的真实权力与责任的界限。

例如财务经理的角色可以分为三级：财务经理、财务副经理1、财务副经理2，财务副经理可继承财务经理的部分权限。

RBAC2模型

在RBAC0模型的基础上，对用户、角色、权限之间增加了限制，包括静态互斥和动态互斥。

静态互斥是指：1）同一个人不能同时担任多个互斥的角色；2）同一个角色不能同时被赋予互斥的权限；3）用户拥有的角色应当是有限的，角色拥有的权限也应当是有限的。

例如，一个人不能同时担任采购经理和财务经理两个角色。

动态互斥是指：1）同一个人不能在同一场景下担任多个互斥角色；2）同一个角色不能在某一场景下同时拥有互斥的权限。

也就是说，同一个人可以拥有多个互斥角色，可以做角色切换，但在同一时间，登录和操作都只能选择某一个特定的角色。例如，一个人可以同时担任财务经理和会计两个角色，但是在登录时必须选择本次作为财务经理登录还是作为会计登录。

RBAC3模型

是RBAC1和RBAC2的合集，即可以支持角色继承，又支持对用户、角色、权限的限制。

基于RBAC的扩展模型

对于大型企业，下属部门和子公司的业务情况复杂，RBAC模型已经很难满足其细颗粒度的管理需求。大型企业中，不同部门和子公司用户的数据权限一般有本部门及下级部门、本部门、本人三种。简单的用户-角色-权限模型已经无法满足复杂的管理需要。

这时，基于RBAC模型我们可以扩展出“岗位”这个概念，作为角色和组织机构以及相应的数据权限的集合。

岗位和角色是n对n的关系，一个岗位下可以有多个角色（一般会限制岗位和组织机构是n对1的关系，一个岗位只能挂在一个组织机构下。

4、结合实际业务的多层权限体系模型

4.1 三层权限管理

一般系统功能相对简单，职能分配明确的系统，使用RBAC模型即可达到权限管理的效果。

例如上述组织机构中的财务科，使用基础的RBAC0模型，设置“财务经理”、“出纳”、“会计”三个角色，在系统中设置每个角色拥有的权限，将角色分配给相应的用户即可。

4.2 四层权限管理

对于使用人员人数较多、组织机构复杂且人员流动大的系统而言，使用三层权限管理，没办法很好地管控每个用户所具备的数据权限。

在这里我们仍然以上述组织机构为例，假设构建一个供各销售分公司使用的CRM系统，这里就需要引入四层权限管理。

四层权限管理的优点：

1）能够精确地管理每个用户的数据权限，确保每个用户只能看到自己职责范围内的数据；

2）减少系统设置的工作量，对于功能权限相同、数据权限不同的用户，无需设置多个角色；

3）具有可扩展性和灵活性，支持组织机构的变更

例如同样是销售总监，销售分公司一和销售分公司二销售总监的功能权限完全相同，但销售分公司一的北方大区销售总监只能看到自己部门的销售数据，不能查看南方大区部门或者销售分公司二的销售数据。

这种情况下，我们可以设置“销售总监”的角色，并分配相应的权限。在组织机构中，新建销售分公司一 – 北方大区组织下“北方大区销售总监”的岗位，为这个岗位分配“销售总监”的角色和“本部门及下级部门”的数据权限。

最后，权限模型只是协助业务部门进行权限管理的工具，最终使用哪种模型、如何使用还是要与业务密切挂钩。一般在系统概要设计完成之后，就可以着手收集用户权限管理的需求，与原型设计同步进行。

另外，虽然B端系统对用户体验的要求没有C端产品高，但是在权限上要给予用户合理的提示。用户无权限的页面或者操作，要明确提示“您暂无此权限，如有需要请联系管理员开通”，避免用户认为是系统问题。