一、前言无论是什么样的后台管理系统，“人员权限”始终是一个不可回避的话题。 无论是移动端还是PC端产品，登录都需要帐户。 但是，对于C端产品，多数情况下用户自己注册就可以了。
后台产品需要内部人员来创建帐户。 每个使用系统的用户都有唯一的帐户，每个帐户都有自己的权限。
许多情况下，除了超级管理隐式洋葱外，还对许多帐户的权限设置限制，以管理不同用户的使用权限问题。
例如，在制作企业使用类软件时，各个部门、职位的权限不同，例如，其他收费产品的收费用户和免费用户的权限也有很大不同。
如果每个用户分别进行权限管理，则系统用户的卷非常大，则会出现以下问题：
许多帐户的权限相同，但每次都重新分配一次；
如果需要修改某一类型权限用户的权限，则不能批量修改。 一个人一个人修改很花时间。
二、经典机型——RBAC此时，聪明产品的先民建立了“角色”的概念，通过抽象权限集来建立角色，通过修改角色权限来控制具有该角色的人的账户权限。
1、RBAC——基于角色的访问控制（Role-Based Access Control ）其基本思想是在用户集合和权限集合之间创建角色集合，而不是直接向特定用户授予对系统操作的各种权限。 每个角色都对应于一组相应的权限。 如果为用户分配了适当的角色，则该用户对该角色具有所有操作权限。
这不需要每次创建用户时都执行分配权限的操作，只需要为用户分配适当的角色，而且角色权限更改远少于用户权限更改，从而简化了用户权限管理并减少了系统开销
根据百度百科RBAC的定义，该模型可以理解为角色通过关联用户、角色关联权限来间接授予用户权限。
2、分类RBAC模型分为RBAC0、RBAC1、RBAC2、RBAC3
RBAC0:是RBAC的核心思想。 任何完全支持RBAC概念的系统的最低要求。
RBAC1:RBAC角色的分级模型。 添加了角色分级概念，允许一个角色从另一个角色继承许可权。
RBAC2:添加了RBAC的约束模型。 添加了一些限制，强调了RBAC不同组件的配置限制。
RBAC3:其实是RBAC2 RBAC1。 称为统一模型，包括RBAC1和RBAC2，利用传递性也包括RBAC0。 这些模型构成了RBAC96模型族；
下面以最基本的RBAC0为例，介绍角色的权限体系。
三、RBAC0 1 .用户-角色-权限之间的关系通过上述分析发现，该模型涉及三个专有名词。 它是用户、角色和权限，以下是我对这三个词的简单定义。
用户：使用系统的人
角色：权限集合；
权限：数据权限、功能权限(页面权限操作权限)；
在此RBAC0模型中，您可以授予角色权限，并将角色与用户相关联以继承与角色对应的权限。 用户和角色、角色和权限是多对多的关系。 用户拥有的权限等于所有角色拥有的权限的并集
然后分析如何巧妙联合这三个名词，构建完整的系统用户权限管理。
2 .用户管理
新用户为2个关键点，第一是需要关联角色，第二是关联组织部门
关联角色： RBAC0模型的关系从图1可以看出，用户和角色之间有多对多的关系，所以假设像图2的用户“吴京”这样，战狼、伪装者的角色有关联，那么他就是战狼、伪装者这两个角色
用户权限可以单独更改，更改用户权限不会影响角色本身的权限。 更改角色权限将更改与角色下相关联的所有用户的相应权限。
相关组织部门：什么是组织部门？ 查看下次分解——权限管理；
2 .权限管理权限可分为数据权限、功能权限类。
数据权限
kkdzxc是账户可以看到哪些数据。 例如，如果一个公司有多个独立的运营中心，如何保证每个运营中心的信息独立性，如何防止运营中心之间相互看到业务数据，这就涉及到数据权限。
数据权限一般由数据权限树控制，但什么是数据权限树？
数据权限树在一定程度上等于公司的组织结构当然，本公司可以根据公司的特性进行修改，不一定要严格遵循公司的部门结构。 如果这个结构能更容易地为公司服务就好了。 下图
例如：如果一家公司下有三个子公司，则每个子公司都是一个独立的业务部门，这样，在为每个子公司的用户分配权限时，只需要将该子公司下的数据放置在他身上
如果业务发票需要跨越公司，则可能需要特殊处理，例如在创建采购订单、选择公司或释放权限时。 因为我不知道哪个公司会合作。
查询页面显示原则：所有与本公司业务相关的文件
该公司业务数据权限的人皆可以查看。以电商中常见的仓库调拨单为例：
此单据可以查看的人员有：
A公司拥有业务组1权限的人员+B公司有B仓权限的业务组的所有人员。有点拗口哈，但不妨碍我们把事儿说清楚。
功能权限
功能权限是页面权限+操作权限的集合。页面权限是指你的系统分为哪些个页面，比如说销售单查询页、商品库存页等等。操作权限是指页面上能看到的：查询、新增、删除、导出等等操作。
页面权限：所有系统都是由一个个的页面组成，用户是否能看到这个页面的菜单、是否能进入这个页面就称为页面权限。
操作权限：用户凡是在操作系统中在任何页面做的任何动作，都是操作权限，如增、删、改、查、导出、审核等等。
以后台系统功能权限为例，如图4，一般来说，功能权限的配置方式都是以模块+页面名称+页面对应的操作为模型进行配置的，这样配置既清晰，出错的概率也比较小。
3.角色管理角色管理是RBAC0模型的关键，以下是角色管理的图文说明：角色的建立主要包括3个模块，基础信息功能权限、数据权限。
其中基础信息和功能权限为必填，数据权限可选填。数据权限一般在用户的账号上再进行配置。
如果角色适用于所有的组织机构那么就可以配上数据权限，如角色是针对ggdkfd一个组织机构建立的，那配置数据权限反而是累赘。
例如：以图3的公司结构为例，如果每个子公司都有自己的财务，并且最后需要汇总到总公司的财务体系下，这时系统如果只建立1个财务角色，那此时，就只需要配置功能权限，数据权限在新增用户的时候对总公司的财务、分公司的财务配置不同的数据权限即可；
如果系统如果分别建立2个及以上个财务角色，1个叫总公司财务，一个叫子公司1财务、子公司1财务，那么每个财务角色就可以在新建的时候把数据权限、功能权限都配置好，新建用户的时候就无需再去配置。
具体角色应该怎么新建，各公司可根据自身的实际情况进行灵活配置。
四、总结
RBAC0模型基本可以满足任何一个系统去建立一套相对完整的权限体系，当然它也存在着一些不足，比如：
一个用户拥有多个角色，多角色之间如果存在互斥关系如何处理？
当角色存在层级关系时如何给角色建立层级关系？
......
这时候我们就需要引入以下这些升级模型：
1、RBAC1：是把RBAC的角色分层模型。增加了角色分级的概念，一个角色可以从另一个角色继承权限。
2、RBAC2：增加了RBAC的约束模型。添加了责任分离关系，规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
互斥角色: 同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。比如财务部有会计和审核员两个角色,他们是互斥角色,那么用户不能同时拥有这两个角色,体现了职责分离原则
基数约束: 一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配
先决条件角色: 即用户想获得某上级角色,必须先获得其下一级的角色
3、RBAC3：其实是RBAC2 + RBAC1。称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。
以上是我根据自己主导过，使用过的系统，得出的对角色权限系统的归纳和总结，有不足之处，希望大家多多交流。
链接：https://www.jianshu.com/p/29c2d7721924