RBAC权限模型

权限

权限，是用户可以访问的资源。包括页面权限、操作权限和数据权限。

1. 页面权限。
   页面权限，即用户登录系统可以看到的页面。由菜单控制。菜单包括一级菜单、二级菜单，只有用户有一级菜单、二级菜单的权限，那么用户就可以访问页面。
2. 操作权限。
   操作权限，即页面的功能按钮，包括查看、新增、修改和删除等。比如，用户点击删除按钮时，后台会校验用户角色下的所有权限是否包含该删除权限，如果包含，则可进行下一步操作，反之，提示无权操作。
3. 数据权限。
   数据权限，即不同用户在同一页面看到的数据是不同的。比如，财务部只能看到财务部的数据，采购部只能看到采购部的数据。解决方案一般是将数据和具体的组织结构关联起来。
   传统权限模型 传统权限模型，直接将权限赋予用户。

RBAC权限模型

RBAC（Role Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联，而不是直接将权限赋予用户。

一个用户拥有若干个角色，每个角色拥有若干个权限，这样就构成了“用户-角色-权限”的授权模型。这种授权模型的好处在于，不必每次创建用户时都进行权限分配的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，减少频繁设置。

RBAC模型中，用户与角色之间、角色与权限之间，一般是多对多的关系。

所谓“多对多”，就是双向的一对多。

单向的一对多
单向的一对多。比如，客户表和订单表。一个客户名下有多个订单。

双向的一对多（多对多）
多对多，即双向的一对多。比如，学生表和课程表。一个学生可以选修多门课程。一门课程有多个学生选修。

RBAC级别

1. RBAC0。用户和角色是多对多，角色和权限是多对多。一个用户拥有的权限，是他所有角色的集合。
2. RBAC1。基于RBAC0，并引入了角色分层的概念，即一个角色分为多个等级，每个等级对应的权限是不一样的。把权限分给用户时，需要分到对应的角色等级。角色等级低时拥有的权限少，角色等级高的权限是所有角色等级低的权限的集合。
3. RBAC2。基于RBAC1，对角色访问进行限制。如
   互斥角色限制。同一个用户分配到两个角色，且角色互斥时，那么系统应该提醒只能选择其中一个角色。比如员工拥有商务这个角色，可以创建结算单并提交给财务审核，这时，就不能赋予这个员工财务角色，否则他就自己提交结算自己审核结算单了。
   角色数量限制。一个用户拥有的角色数量是有限的；一个角色被分配的用户数量也是有限的。
   先决条件限制。用户想获得某个上级角色，必须先获得其下一级的角色。比如想获得产品总监的权限，那就需要从产品助理这一角色开始，再到产品经理角色，最后到产品总监角色。
4. RBAC3。基于RBAC0，对RBAC1和RBAC2进行了整合，是最全面的权限管理。
   用户组
   当平台用户的基数增大，角色类型越来越多时，而且一部分人具有相同的属性，比如财务部的所有员工。

用户组

当平台用户的基数增大，角色类型越来越多时，而且一部分人具有相同的属性，比如财务部的所有员工。
如果直接给用户分配角色，管理员的工作量就会很大。
如果把相同属性的用户归类到某个用户组，那么管理员直接给用户组分配角色，用户组里的每个用户即可拥有对应的角色，以后其他用户加入用户组，便可自动获取用户组下的所有角色；用户退出用户组，则自动撤销用户组下的所有角色，无需管理员手动管理角色。

举例1：一个部门是一个用户组。
将部门和角色进行关联。当用户加入某个部门后，就自动获得该部门拥有的全部角色，不需要管理员手动授权，大大减少了工作量。同时，用户如果被调去其他部门，角色将自动调整。

举例2：一个岗位是一个用户组。
每个部门下会有很多岗位，比如财务部有财务总监、会计、出纳等岗位。这些岗位虽然同属财务部，但每个岗位的权限是不同的。职位高的拥有更多权限，总监拥有所有权限，会计、出纳拥有部分权限。特殊情况下，一个人可能身兼多职。

部门、岗位就是具有上下级关系的用户组。

权限框架

1. Spring Security
2. Apache Shiro
3. Sa-Token
4. 自研