一、前言
权限一句话来理解就是对资源的控制，对web应用来说就是对url的控制，关于权限可以毫不客气的说几乎每个系统都会包含，只不过不同系统关于权限的应用复杂程序不一样而已，现在我们在用的权限模型基本上都是以RBAC为基础进行扩展的，我们今天就将RBAC权限模型进行下介绍。
二、RBAC模型
RBAC是Role-BasedAccess Control的英文缩写，意思是基于角色的访问控制。RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What(Which)进行How的操作，也就是“主体”对“客体”的操作，其中who——是权限的拥有者或主体（如：User、Role），what——是资源或对象（Resource、Class)
RBAC其实是一种分析模型，主要分为：基本模型RBAC0（Core RBAC）、角色分层模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）。
1）RBAC0
RBAC0，它是RBAC0的核心，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。RBAC0定义了能构成RBAC控制系统的最小的元素集合，RBAC0由四部分构成：
a、用户（User）
b、角色（Role）
c、会话（Session）
d、许可（Pemission）,其中许可又包括“操作”和“控制对象”其中许可被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的许可。会话是动态的概念，用户必须通过会话才可以设置角色，是用户与激活的角色之间的映射关系。
图中，用户与角色是多对多的关系；角色和许可也是多对多的关系；用户与会话是一对一关系；会话与角色是一对多关系；
2）RBAC1
RBAC1，它是RBAC角色的分层模型，RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念，有了继承那么角色就有了上下级或者等级关系
3）RBAC2
RBAC2，它是RBAC的约束模型，RBAC2也是建立的RBAC0的基础之上的，在RBAC0基础上假如了约束的概念，主要引入了静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。
SSD是用户和角色的指派阶段加入的，主要是对用户和角色有如下约束:
a、互斥角色：同一个用户在两个互斥角色中只能选择一个
b、基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的
c、先决条件约束：用户想要获得高级角色，首先必须拥有低级角色
DSD是会话和角色之间的约束，可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。
4）RBAC3
RBAC3，它是RBAC1与RBAC2合集，所以RBAC3是既有角色分层又有约束的一种模型
以上就是RBAC模型的四种设计思想，现在我们用的权限模型都是在RBAC模型的基础上根据自己的业务进行组合和改进。
三、我们的权限模型
先大概解释下我们的业务，我们做的是教育行业高校云平台，每个学校都可以在我们平台进行注册，注册完成后可以享受一些基础的服务，当然了不同级别的用户享受的基础服务是不同的，这些基础的服务包括新生注册管理、基础系统管理、考试系统管理、评教系统管理等模块，每个模块都相当于一个子系统，每个子系统都有各自的功能，每个功能也都有各自的相关的页面，而所有的子系统、页面以及页面上的功能按钮都是需要我们权限进行管理，所以我们的权限管理相对来说任务也是比较繁重的。
我们先来看下我们权限管理模块的类图：
核心还是基于用户、角色和许可的RBAC模型，只不过我们将这三者分别进行了相应的扩展：
用户
无论哪个用户首先它必须是属于某个部门的，部门是行政单位，而某个部门也可以包含多个用户，所以部门和用户的关系为1对多的关系；
先说一下为什么要有用户组的概念，如果有一类的用户都要属于某个角色，我们一个个给用户授予角色，重复工作特别多，所以我们把这么一些用户进行分类，也就是用户组，这样的话，我们直接对用户组赋予角色，减少重复的工作量，这样达到的目的是这，用户拥有的所有许可，就是用户个人所属角色拥有的许可与该用户所在用户组所属角色拥有的许可之和。一个用户可以属于多个用户组，一个用户组也可以包括多个用户，所以用户与用户组是多对多的关系；
角色
角色是一定数量的许可的集合，许可的载体，一个角色可以包含多个用户，一个用户同样的也可以属于多个角色，所以角色与用户的关系为多对多的关系。同样的一个角色可以包含多个用户组，一个用户组也可以属于多个角色，所以角色和用户组也是多对多的关系；
许可
许可我一般称它为权限，它包括控制对象和操作，控制对象一般为资源，包括菜单、页面、文件等资源，而操作一般包括增删改查等，图中“系统操作”就是操作，“菜单信息”就是控制对象；
菜单信息中的每个菜单都会有增删改查等操作，所以菜单信息与系统操作是一对多的关系；
我们给角色授予权限时，授予就是颗粒最小的权限，所以我们将系统操作权限授予某些角色。一个角色可以拥有多个系统操作，一个系统操作同样也可以属于多个角色，所以系统操作和角色为多对多的关系。
到这里我们就将我们的权限模型之间的关系基本上介绍完毕了，在类图中的两个类之间的多对多的关系在数据库中会出现第三张表，所以下面我们来看下我们的数据库中表的关系图：
四、改进
现在这个权限模型已经开发出来投入使用了，当然了现在的模型也不一定是最好的，只能说针对于现在的系统的规模是比较合适的，对于现在的权限模型还是有可以扩展的地方，其实就是类图中的菜单信息，在系统中我们只是粗犷的将子系统名称、子系统菜单、子系统菜单页面元素、文件等这些资源全部放到了一个表中即菜单信息表，在表中我们利用类型进行具体区分，同时利用上下级关系来管理他们之间的层次关系，但是在这个表中冗余的数据会特别多，我觉得如果可以更进一步改善的话，可以考虑将菜单表按照菜单类型进行拆分，然后再来一张表资源关系表来管理这些类型资源之间的关系。
五、总结
这篇文章我们将RBAC权限模型的4种设计思想进行了介绍，接下来我将我们自己项目中的权限模型进行了详细的介绍，最后还针对我们当前的权限模型提出了自己的一点想法。如有异议的地方，请大家多多指正。