业务系统权限问题解决方案[节选]
1 系统权限设计概览
1.1 概述
权 限管理是保证系统安全和灵活性的重要部分。业务系统通过对不同的用户分配不同的权限来明确和限定用户的职责。用户的权限由管理员在后台管理页面进行管理，
用户的权限的更改必须经过审批才能生效。权限更改的操作包括授权和收回权限，以及更改权限的应用范围。后台管理的权限分为全局级和部门级，分别可以对系统 进行全局的管理和部门的管理。同时，用户帐号可以和所在的 windows 活动目录进行整合，以实现“一次登录，自动认证”。
1.2 权限的表现形式
权限的表现形式分为 菜单级权限、按钮级权限、运行时权限检查三种。菜单级权限表现在系统的菜单树结点的不同、按钮权限表现为列表或内容页面可见的按钮不同，而运行时权限检查是在用户执行操作以后进行检查。
1.3 人员角色和默认权限
业务系统中，人员角色分为 业务人员、领导、部门管理员、全局管理员。
|
角色 |
默认权限 |
|
|
业务人员 |
业务办理 |
|
|
领导 |
业务和文书审批权限 |
|
|
管理员 |
部门管理员 |
部门级的管理 |
|
全局管理员 |
全局级的管理 |
|
其中除部门管理员和全局管理员关系互斥以外，其他的角色都可以并存，也即同一个人可以在管理员的调整下担任多种角色。
1.4 二级权限
权限的分级是保证系统灵活性的重要手段。为保证系统的安全和方便管理员进行管理，系统权限分为全局级和部门级。本文将在第2节对此进行详细的描述。
1.5 权限审批
权限审批是指对用户的权限的更改需要经过审批方能生效，旨在避免由权限分配带来的漏洞、提升系统的安全性。系统通过内置的策略保证权限审批的合理性和不可回避性。本文将在第3节对此进行详细的描述。
1.6 与 windows 活动目录的整合
某些机构使用windows 活动目录来管理计算机和用户，业务系统具备与其交互的功能。通过在用户信息添加对应的域用户名，实现了域用户与业务系统用户的绑定，用户登录域以后不需要再重复登录业务系统。
2 二级权限
2.1 概述
二级权限即将系统管理权限分为两级：全局级和部门级，分别可以对系统进行全局的管理和部门的管理。设计的目的是通过权限的下放减轻全局管理员的维护负担和职责，更重要的是方便具体业务部门按照需要调整权限和配置业务功能。
2.2 设计要求
u 在系统中设置两级管理员—全局管理员和部门管理员。全局管理员管理组织机构、业务流程、等全局性的资源；部门管理员负责管理部门内部的具体事务，例如人员权限、业务流程、操作界面等
u 部门管理员对用户的权限的修改需要经过审批，详见本文第三节
u 全局管理员和部门管理员的主要权限及差异见下表
|
权限名 |
全局管理员 |
部门管理员 |
|
代码维护权、登陆日志 |
全部 |
无 |
|
组织结构维护权 |
全部 |
只有本部门的岗位维护权 |
|
人员维护权 |
全部 |
可以管理本部门的员工的资料,可以创建、删除本部门的用户、修改本部门的用户资料，部门管理员可以对本部门的员工进行在权限列表中列出的操作，部门管理员不能修改员工的部门，部门管理员不能将任何人设置为全局管理员 |
|
人员权限管理权 |
全部 |
可以管理用户的属于本部门的流程和业务的查询权限，但不能管理用户的不属于本部门的流程和业务的查询权限（在相关的列表中应该过滤不属于本部门的流程和业务的查询权限，但注意保存的时候不应该影响到未列在列表中的权限） |
|
流程维护权 |
全部 |
只有本部门的流程的修改权 不能新建、删除流程 |
|
业务办理权限 |
无 |
有 |
|
|
|
|
2.3 实现步骤
1)
给员工设置级别，0级为无管理权，1级为部门管理员，2级为全局管理员，员工级别存储于用户信息表中
2)
在员工的权限设置中，加入对员工的级别进行显示和修改的操作
3)
加载菜单时进行判断，非管理员不显示后台管理节点，部门管理员显示部分后台管理节点
4)
部门管理员的操作界面，只显示与本部门相关的权限，通过“部门”属性过滤掉与部门无关的项目
5)
对于全局的管理项目，采用隐藏按钮和运行时判断的方法拒绝部门管理员进行管理操作
3 <权限分配>和<权限审批>分开
3.1 概述
基于安全的考虑，将<权限分配>和<权限审批>分开，即<权限分配>管理员只负责进行权限的分配和更改，但是所分配和更改的权限必需通过<权限审批>管理员的审批才能生效。全局管理员和部门管理员都这样区分成两类。这在系统设计的时候是没有预料到的，需要重新进行设计。
3.2 设计要求
u 任何权限的分配和删除都需要审批，在通过审批前权限的更改不应该生效。
u 用户在被修改权限以后 到 权限的修改被审批通过或拒绝 以前，用户应该仍然具有其在其权限被修改之前的权限。
u 如果用户有未审批的权限更改申请，则不能进行新的权限更改申请，以防止并发冲突。
u <权限分配>的权限和<权限审批>的权限互斥，即同一个人不应该同时具有分配和审批两种权限。
u 任何人不能审批自己分配的权限。
u 系统内置两个管理员，一个具有<权限分配>的权限，一个具有<权限审批>的权限。
u <权限分配>的权限和<权限审批>的权限都可以重新进行分发，即管理员可以将此<权限分配>给同级或更低级别的管理员，在实际使用中，可能会将<权限分配>和<权限审批>权限下放到部门中，即每部门都有各自的管理员进行权限的分配和审批。
u 从逻辑上来说，通过系统内置的互斥策略（<权限分配>的权限和<权限审批>的权限互斥），只要保证<权限分配>管理员和<权限审批>管理员的帐号分开管理，就可以避免权限权利上的漏洞。<权限分配>管理员没有<权限审批>权限，如果他需要给某人分配<权限审批>的权限，也必须经过<权限审批>管理员的批准；而<权限审批>管理员由于本身不具备<权限分配>的权限，因此也不能给其他用户分配权限。
3.3 实现步骤
1)
在后台管理中，添加<权限审批>的权限，而<权限分配>的权限继续沿用。
2)
新建两个表，主表（PrivilegeCacheMain）和从表(PrivilegeCacheDetail)，主表记录对某人的权限更改信息，从表记录具体的权限差异，两表使用主表ID进行关联。
3)
更改<权限分配>的页面，考虑到尽量少的修改系统设计，我们在分配权限时，不直接将结果集写入权限表，而是将分配结果和原数据的差异缓存在数据库中，同时也可以将预计要运行的SQL脚本也保存到数据库中，在分配权限时判断是否会导致用户同时具有<权限分配>和<权限审批>两种权限，如果有，则拒绝分配操作（提示修改）。
4)
新增<权限审批>相关的页面。在具有<权限审批>的权限的用户的后台管理界面中增加<权限审批>节点，指向<权限审批>的页面，此页面列出权限已发生更改但未审批的用户的列表，此列表连接至更改详细信息页面。权限更改的详细页面列出用户增加的、删除或更改的权限的列表，可以进行审批通过和拒绝操作。通过，则运行缓存的SQL语句或者根据具体的更改构造的SQL 语句；拒绝，则将缓存清除。在通过审批前，应该判断是否会导致用户同时具有<权限分配>和<权限审批>两种权限，如果有，则拒绝审批通过操作。
3.4 数据结构
主表（PrivilegeCacheMain）的数据结构
|
列名 |
类型 |
描述 |
|
CacheMainID |
Int |
标识 |
|
UserID |
Int |
被修改权限的用户ID |
|
ModifyUserID |
Int |
执行<权限分配>的用户ID |
|
ModifyTime |
DateTime |
执行<权限分配>的时间 |
|
AuditUserID |
Int |
执行<权限审批>的用户ID |
|
AuditTime |
DateTime |
执行<权限审批>的时间 |
|
AuditResult |
Int |
审批结果（0：未审批，1：通过，-1：拒绝） |
|
SqlToRun |
NText |
通过以后要运行的Sql脚本 |
从表 (PrivilegeCacheDetail)的数据结构
|
列名 |
类型 |
描述 |
|
CacheMainID |
Int |
对应的主表记录的标识ID |
|
PrivilegeName |
NvarChar(20) |
权限名 |
|
OperationName |
NvarChar(20) |
更新操作（添加、删除、修改） |
|
OperationRemark |
Nvarchar(500) |
操作描述 |
|
PrivilegeType |
NvarChar(20) |
权限类别（流程查询权限、业务查询权限等） |
