权限管理是管理后台不可或缺的一个重要模块。通过对用户的授权，使得不同用户在登录成功后，可以操作不同的菜单和数据，这样就可以对数据形成一定的保护作用。对于权限管理模块的设计，本人也经历了不少版本。
第一个版本，也是最low的一个版本。早不记得当时的上司讲了啥，只记得脑袋一拍，这个好办，就给每个用户赋予不同的权限编号吧。
为每个菜单赋予一个编号，能够操作这个页面的用户，都会拥有这个编号，多个权限编号逗号分隔。菜单都是死的，哪个菜单对应哪个编号，也是写死的。
这样做的弊端显而易见：
1. 新加一个菜单，就需要为该菜单添加一个编号，添加编号就要修改程序；
2. 新加的菜单需要重新授权给需要的用户；
3. 每个用户都需要重复授权，不管权限是否一样。现在想来，真是小白一枚，听啥是啥。好在用户不多，不然做授权的管理员肯定很累吧。
RBAC0 模型
第二个版本，使用现成的设计。这一次紧跟前辈们的脚步，把菜单做成活的，增加了角色的设计，用户与角色多对多的关系，角色与菜单多对多的关系。没想到这就是标准的权限设计RBAC模型。
RBAC（Role-Based Access Control）基于角色的访问控制。其基本思想是对系统操作的各种权限，不是直接授予具体的用户，而是在用户集合和权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了某个角色，就拥有该角色下的所有操作权限。
优点：不必在每次创建用户时，就为用户分配权限的操作，只需分配角色。角色的权限变更比用户的权限变更要少得多，大大减少了系统开销。权限，是用户可以访问的资源，包括页面权限、操作权限、数据权限。
页面权限：用户登录后就可以看到的菜单：一级菜单、二级菜单，有了菜单就可以看到菜单下的页面。操作权限：页面上的操作按钮，新增、修改、删除、审核等等，大部分系统要求“可见即可操作”，能够看见的按钮都是可以操作的按钮，不能操作的按钮需要隐藏。
数据权限：不同用户在同一页面所看到的数据是不同的。销售一部和销售二部的用户，他们只能看到属于自己的销售数据。老板又说了，一个用户一个角色就够了。ok，把设计裁剪一下。
RBAC权限设计模型，又称RBAC0模型。还有其他版本吗？没错，还有RBAC1、RBAC2、RBAC3权限设计模型。
RBAC1 模型
RBAC1模型引入了角色继承的概念。
每个角色都可以有一个上级角色。上级角色拥有下级角色所拥有的权限。
再复杂一点，一个角色可以拥有多个父级角色。这个就看业务场景，是否需要这么设计。
RBAC2 模型
RBAC2引入了角色互斥、基数约束、先决条件约束。角色互斥，一个用户能拥有角色A，就不能拥有角色B，角色A和角色B是互斥的。也可以是权限互斥，权限A和权限B不能在一个角色里。
基数约束，一个角色被分配的用户数量有限；一个用户拥有的角色数量有限；一个角色被分配的权限数量有限；以便控制高级权限在系统中的分配；三个约束看业务需求任意选。先决条件约束，想获得某个上级角色，必须先拥有下级角色。
RBAC3 模型
RBAC3基于RBAC0，将RBAC1、RABC2进行了整合，是最全面的权限设计模型。其中涉及到的概念有用户组、组织、职位。
1. 用户组平台用户多，角色类型增多，有一部分人具有相同的属性。比如生产部的所有员工等，如果直接给这些用户分配角色，就会增加管理员的工作量。如果给这些用户分组，并给用户组分配角色，用户组里的每个用户都具有用户组下的角色。如果用户退出用户组，就撤销用户组下的角色，这样就大大减少了管理员的工作量，无需管理员手动管理角色。用户组又分为具有上下级关系的用户组、普通用户组。具有上下级关系的用户组，和部门、职位关联起来。按照部门和职位对用户进行分组。普通用户组，没有上下级没关系，和部门职位也没有关系。纯粹地对用户进行分组。
2. 组织对于组织结构复杂的公司，可以把组织架构和角色关联起来。一旦把某个人加入某个组织，该用户就会拥有该组织下的所有角色。
-
职位每个部门下有很多职位，职位不同，职位的权限也不同。把职位和角色关联起来，一旦赋予某人某个职位，该用户就会拥有该职位下的所有角色。特殊情况下，一个人可以拥有多个职位。
在实际开发中，根据不同的业务需求，会有各种各样的演变，业务逻辑复杂的，权限系统也复杂，想要做出通用全面且高效的权限模型，还是非常不容易的。现在就把用户组、组织、职位、角色互斥、基数约束汇总起来画个草图。
最全面的RABC模型
最后总结
权限模块是一个系统中最基础也是非常重要的一个模块。要考虑角色继承就使用RBAC1模型，要考虑角色互斥、基数约束、先决条件约束就使用RBAC2模型。中小型公司使用RBAC0模型就足以使用，超大型的公司再考虑RBAC3设计模型，也可以根据实际的业务需要进行适当的裁剪。
网友评论