这是《后台产品设计指南》系列文章的第4篇内容，更多精彩可以点击下方链接查看。
随着系统用户的增多，如何科学高效地管理用户权限是平台管理员必须考虑的问题。本文会和大家介绍一下权限系统的产品设计。
RBAC
RBAC（基于角色的权限控制）模型是为了解决系统中的权限管理问题。在用户和权限基础上引入了角色这个概念，这样通过对角色的管理极大程度地降低了用户和权限之间的耦合。
需要说明的是RBAC只是权限模型的一种，相对比较成熟所以使用比较广泛。其他的权限模型也是可以使用的，比如ACL访问权限列表、ABAC基于属性的权限控制、PBAC基于策略的权限控制、Auth基于节点的权限管理系统。
权限的分类
1.菜单
菜单是最顶级的分类，在复杂的系统中菜单经常是多级的，比如二级、三级，在菜单层面进行限制是最直接的。
一些简单的系统中使用不到RBAC，经常是在配置文件直接指定角色的菜单，而不需要开发完善的后台管理界面。
2.页面
在成熟的系统中，菜单下面往往有多个页面，比如运营管理这个大模块下面可能包含了banner管理，插屏管理，开屏广告管理等等。每个人需要使用的页面不一定一样，这样就需要对页面进行设置。
3.页面元素
页面中的元素可以是添加按钮，保存按钮，导出按钮等等。有些人在页面中没有添加权限，这个时候可以屏蔽掉添加按钮这个页面元素。
4.数据
数据层面的理解相对复杂一点。这里列举2个例子说明一下。第一，销售总监需要看到多个销售主管的数据，销售主管只能看到下面销售的数据，销售只能看到自己的数据。第二，房产频道小编只能看到该频道的资讯文章，而财经商业频道的小编能看到财经商业的资讯文章，总编则能看到全部频道的下的内容。数据权限一般需要根据城市、部门等多因素来进行设计。
数据范围的限定包括前端和后端两种模式，仅从前端限制是不够的，还需要在数接口上做限制，保证安全性。
RBAC分类
1.基本模型RBAC0
最基础的类型，用户与角色，角色与权限之间都是多对多关系。绝大多数后台系统的权限系统是属于这个类型。
2.角色分层模型RBAC1
简单来说，就是把角色再划分等级，每个等级划分不同的权限。角色之间有了上下级的关系，可以继承角色的权限。比如销售总监-销售主管-销售这个结构就可以使用RBAC1模型。
3.角色限制模型RBAC2
相当于在RBAC基础上增加了一些约束条件。主要有以下三个方面：
角色互斥约束：是指在系统运行中，只可以同时激活运行时互斥角色集合中的一个角色。比如财务系统中一个人不能同时是会计和出纳。
角色基数约束：是限制某一个用户最多被分配或者激活的角色数目，或者限制某一个角色最多被赋予的权限数目。比如OA系统中的管理员数是有上限的。
先决条件角色约束：是指某些用户只有在己经拥有特定角色的前提下，才能被分配到某种角色，或者某种角色只有在已经被分配到特定权限的前提下，才能被赋予某些权限。比如前面提到的OA管理员必须是有总监以上级别角色的前提下，才能被设置为管理员。
4.统一模型RBAC3
RBAC3其实就是前面几种情况的合集，既有角色分层，也包括可以增加各种限制，一般只有在非常复杂的系统中才会用到。
RBAC注意事项
无权限场景
不同用户具备的权限是不一样的，用户A复制链接给用户B，如果用户B没有权限，应该进入统一的缺少权限提示页面，这个页面和404是不一样的。前者表示用户缺少对于权限，后者表示页面出现错误。
用户组
随着用户角色的增加，将用户与角色匹配这个步骤很多时候是重复的，而大多数岗位的角色是固定的，特殊的人再特殊管理即可。这时候可以通过增加用户组的概念，进一步进行解耦，这样即符合用户的实际场景，也便于在数据层面做权限控制。
权限系统对于后台产品非常重要，在产品设计的初期就应该考虑，选择适合自己的方案，避免在后期更改造成巨大的成本损耗。
在写作过程中，如果有意见或者想法，欢迎有兴趣的读者添加我的微信一起交流探索，共同进步。
