序言：
权限模块是MIS系统中不可或缺的重要组成。员工在进行正常的访问前，服务器往往都需要认证员工的身份。确认员工是否授权，也就是进行访问控制。访问控制管理允许被授权的主体（个体或团体组织）对某些资源的访问，同时拒绝向非授权的主体提供服务。权限模块的逻辑模型一般形式如下：
谁（员工/角色）对什么（应用模块）是否具有某种操作的授权（授权状态：grant、deny、revoke等）。即who + what + how操作模型。
目前业界比较流行的授权模型有RBAC、ACL等。本文主要阐述CSD权限控制模块的逻辑组成，童鞋们可以根据项目的实际情况和具体架构，在可维护性、灵活性、完整性等方面对目前的权限模型进行自己的灵活定制。
1. 什么是RBAC?
关于访问控制，人们提出了各种保护数据并加以控制的安全模型，如自主访问控制（Discretionary Access Control，DAC）、强制访问控制（MandatoryAccess Control，MAC），它们通常都是基于员工-组的安全模型。而RBAC（Role-Based Access Control）具有简化管理的优越性，它更适合大型系统的管理应用。访问控制策略体现在RBAC模型里是员工-角色、角色-权限和角色-角色之间的关系。NIST（National Institute ofStandards and Technology）制定的RBAC模型体系由4个模型组成，分别是基本模型RBAC0，角色分级模型RBAC1，角色限制模型RBAC2和统一模型RBAC3。
2. RBAC模型体系简介
2.1. RBAC0
（1）. U：表示用户集；R：表示角色集；P：表示权限集；S：表示会话集：
（2）. PR：P×R，是权限到角色的多对多指派：
（3）. UA：U×R，是用户到角色的多对多指派：
（4）. SU：S→U，会话和用户的单一映射，user(sn)表示创建会话sn的用户；
（5）. SR：S→R，会话和角色子集的映射，roles(sn)表示会话sn对应的角色集合；
（6）. 会话sn具有的权限集 P(sn)。
2.2. RBAC1 & RBAC2
RBAC1引入角色继承关系，（一般继承关系，受限继承关系），RBAC2模型增加了责任分离关系，它规定了角色被授予员工，或者权限被授予角色时，以及当员工在某一时刻激活某一角色时，所应遵循的强制性规则。
2.3. RBAC3
RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系
3．RBAC模型的实现
这里，主要从授权模型和权限校验两部分来讨论实现思路。
3.1 授权模型
建立如下授权模型：
下面，针对授权模型中的几个关键部分进行一下描述：
A． 授权
按照RBAC模型，在授权时分为配置资源以及资源的操作、授予角色对资源的操作权限，分配角色给员工这几步来完成，其中：
a. 资源配置以及资源的操作需要维护资源与资源操作之间的关联模型。
b. 授予角色对资源的的操作权限需要维护资源与角色之间的关联模型。
c. 分配角色给员工需要维护角色与员工之间的关联模型。
d. 权限的继承通过角色的自关联完成，即角色可拥有子角色，子角色继承父角色的权限
B． 权限的排斥与包含
权限的排斥与包含，是通过在资源的操作权限模型中，增加自关联模型以及定义哪些资源的操作权限是排斥和包含的，在授权时可以看到同样需要维护的只是资源权限的自关联模型。
3.2 资源权限校验
根据上面的授权模型，在作资源权限校验的时候需要经过以下几个步骤：
A. 判断员工所在的角色是否拥有对资源进行操作的权限；
B. 递归遍历员工所在角色的父角色，判断是否拥有对资源进行操作的权限；
备注：整个过程是一个递归过程，当遍历员工本身的角色找不到相应的操作权限时，开始进行父类角色的递归查找。可以看出，它和JVM加载class前进行唯一加载判断的法则有着一致的顺序：自底向下判断是否加载过（是否具有操作权限）。
C. 数据权限的校验
RBAC模型将数据映射为RBAC中的资源，对数据的操作则映射为资源的操作，然后将此资源以及资源的操作构成的权限授予角色，将角色分配给员工完成数据权限的授权过程。
备注：该模型包含数据权限的继承（自关联资源模型），数据权限授予主体的多样性。
4．CSD的权限控制模型
CSD权限控制引入了员工和组织机构之间的关联模型，但角色之间的简单继承关系带来了大量的数据冗余，下面是CSD的权限控制ER模型:
备注:
涉及到的数据表如下：
APP_USER:登录用户相关信息
APP_ROLE:系统角色表
APP_PERMISSION:系统权限表
APP_ORG:组织信息表
APP_ROLE_PERMISSION:角色和权限对应表
APP_USER_ROLE_ORG:用户在组织中具有的角色信息表
