在项目中自研了一套专门针对权限管理的框架，其基本思想基本来源与RABC，首先引入一些基础概念。RBAC是基于角色的访问控制（Role-Based Access Control ）在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。
RBAC介绍。
RBAC认为授权实际上是Who 、What 、How 三元组之间的关系，也就是Who 对What 进行How 的操作，也就是“主体”对“客体”的操作。
Who：是权限的拥有者或主体（如：User，Role）。
What：是操作或对象（operation，object）。
How：具体的权限（Privilege,正向授权与负向授权）。
然后 RBAC 又分为RBAC0、RBAC1、RBAC2、RBAC3
- RBAC0：是RBAC的核心思想。
- RBAC1：是把RBAC的角色分层模型。
- RBAC2：增加了RBAC的约束模型。
- RBAC3：其实是RBAC2 + RBAC1。
1.RBAC0，RBAC的核心
2.RBAC1，基于角色的分层模型
3.RBAC2、是RBAC的约束模型。
4.RBAC3、就是RBAC1+RBAC2
在参与到的项目中基于RBAC思想，用用户表 关联 用户角色表，用户角色表关联 角色权限表。根据Shiro的设计思路，用户与角色之前的关系为多对多，角色与权限之间的关系也是多对多。在数据库中需要因此建立5张表，分别是用户表（存储用户名，密码，盐等）、角色表（角色名称，相关描述等）、权限表（权限名称，相关描述等）、用户-角色对应中间表（以用户ID和角色ID作为联合主键）、角色-权限对应中间表（以角色ID和权限ID作为联合主键）。
而我本人项目中，在业务中固定了投资者的角色，而设定了从用户到角色这一层是一对多的关系，角色到权限也是一对多的关系，因此就是三张表。但是在设计角色权限的时候，对于（每一个功能菜单点，只有增删改激活这几个粒度控制了）二级菜单采用了固定的（二进制按位数取&运算，该算法的特点是对于2的幂指数求和[比如2,4,8,16...]之后&自身，求和中包含自身结果仍等于自身，否则为0），只能横向扩张，固定了（增删改激活）按钮，扩展性不是很好。解决方案也只能再多加一张映射关系表，满足多对多的关系，如此才能解决问题。
而在shiro这里严格按照RBAC思想来实现，在角色和权限是多对多的关系，就避开了上述限制。
