0.引言
关于权限系统的设计，从信息系统诞生之初就被广泛关注，也已经存在很多成熟的模型，本文中所采用的基于角色的权限模型[1]就是其中的一种。但以往权限系统的设计很多时候并没有顾及开发上的便利性。 随着 ORM[2]框架的广泛应用，数据库的访问得以大幅度简化，目前新开发的信息管理系统基本上都引入了 ORM 框架。 这为权限系统的开发提供了新的机遇和挑战。本文将介绍 ORM 框架下的权限系统，特别考虑了和其它模块的集成问题。
1.设计
1.1 系统结构
权限管理系统分为底层的数据访问、中层的业务逻辑和上层的权限管理三个层次模块，其中中层的业务逻辑划分为权限判定、权限设置和口令三部分。上层的权限管理部分调用权限判定、权限设置和口令三个模块实现权限管理的相关功能，而功能模块只与权限判定部分交互，使用权限判定模块的方法判断用户是否具有当前操作的权限。
1.2 功能需求
从权限的动能角度讲，其需要可以归为以下几点：
1.2.1 用户是基于角色的。 每个用户属于，且仅属于一个角色。
1.2.2 系统中存在至少一个超级用户，且该用户具有所有权限。 只有超级用户具有用户管理权限。
1.2.3 超级用户可以仅仅针对某一个人定义权限。
1.2.4 对于权限的判断，有以下两种基本形式，其它形式是这两种形式的演化：
1.2.4.1 不含参权限。 例如用户是否具有添加用户、管理文章分类的权限等。
1.2.4.2 含参权限。 例如用户是否具有某一个类别的项目的管理权限，这里某一个类别即为参数。
1.3 类设计
从 ORM 设计的方式上讲，首先要考虑的是 O(Object)，即业务逻辑层的设计。 权限系统的核心类包括 User 类、UserRole 类、Power 类、HasNoPowerException 类和 PowerItem、UserRoleType 两个枚举。
UserRoleType 枚举表示系统中的用户角色类型， 例如管理员 、专家和企 业 用 户 。 UserRole 类 表 示 用 户角色，其最主要的方法是HasPower 方法，用于判断该用户角色是否具有某一项权限。
User 类表示用户，其中的 HasPower 方法与 UserRole 中的类似，用户判断该用户是否具有某一项权限。 User 含有对 UserRole 的引用，表示用户属于哪个角色。
UserRole 和 User 都拥有一个权限 Power， 即拥有一个 Power 的引用。 Power 真正处理权限的判断，UserRole 和 User 的 HasPower 方法最终委托给 Power 的 HasPower 方法。
PowerItem 枚举描述的是系统中的权限项目。 该枚举是定值枚举，即每定义一个枚举项，则其对应的值即被永久占用。 及时该枚举项被删除，其对应的值则永久失效，不能被新定义的新枚举项所使用。这种方式是为了保证在枚举项目发生改变时，数据库中的现有数据对应正确的枚举项。
HasNoPowerException 表示用户没有该操作的执行权限 ， 该异常的抛出通常意味着系统受到了安全攻击。
1.4 数据库设计
采用 ORM 框架后，数据库的设计与类设计直接映射。类设计中的UserRole、User、Powers 三个核心类直接映射为三个同名的数据库表 ，类的属性映射为字段。
2.实现
对于权限的判定，分为两部分，一种是基本权限的判定，另一种是对衍生权限的判定。 前者是归属于权限部分，后者则是有功能模块负责。 衍生权限的最终实现又是依赖于基本权限。例如有一个衍生权限：“某一个项目的编辑权限”，其定义为：
1)如果该项目的状态为已结项，则用户必须具有“结项项目管理”这一基本权限。
2)当项目不处于结项状态时且用户具有该项目的管理权限 ，则该用户具有该项目的编辑权限。其中该项目的管理权限是另一项衍生权限。
3) 当该项目的状态为等待立项信息且该用户是该项目的负责人或委托负责人时，用户具有该项目的编辑权限。
4)其它情况下，用户不具有该项目的编辑权限。
该方法代码实现为：
public bool CanEdit(User user) {
if (_State == ProjectState.ProjectEnd && !user.HasPower(PowerType.
ManageFiNIshProject))
return false;
if (CanManage(user))
return true;
if ((IsPrincipal(user) || IsPricipalDelegate(user))
&& (_State == ProjectState.WaitingStartInformation))
return true;return false;
}
该段代码隶属于 Project 类，其中使用了 User.HasPower 这一基本权限的判定方法，还是用了 CanManage 等，IsPrincipal 等其他的衍生权限。
所谓基本权限是指 PowerItem 中定义的权限， 这些权限被储存在Power 表的 Powers 字段 中 。 基 本 权 限 的判定通过是调用User 的HasPower 方法实现的。User 的 HasPower 首先会判断该用户是否是超级用户，如果是，则不需要进一步的判定，直接返回 true，即该用户具有需要判定的权限。这实现了“超级用户具有所有权限”这一业务规则。然后 HasPower 方法会根据用户是否是自定义权限来选择是权限的判定工作委托给自身的 Power 还是委托给对应的用户角色。而 UserRole 的 HasPower 方 法 则 会 调 用 其 对 应 的 Power 的HasPower 方法， 所以 Power 类的 HasPower 最终包含了基本权限的判定。Power 类的 HasPower 提供两个重载，分类用于提供普通权限和含参权限的判断， 而普通权限的判定可以认为是含参权限的一种特殊情况。所以最终，含参权限的判定方法是真正的实现。判定权限由私有方法 hasPower 执行。 hasPower 私有方法会识别Powers 中保存的 “0,1,1,0,1,1”格式的权限信息 ，根据给出的枚举值对应位置上的权限是 1 还是 0，返回 true 或 false。最后，对于含参权限，要根据其参数进行进一步判断。通过基本权限和衍生权限的结合，最终实现了“某一个项目的编辑权限”这一权限的判定。
3.结论
本文讨论了基于 ORM 框架下的权限管理系统的层次及模块划分，总结了其功能需求，并在此基础上给出了类设计及数据库设计。并通过一个具体的权限判定给出了描述了对于复杂业务逻辑下权限判定方法的实现。文中描述的权限系统通过 ORM 实现了业务逻辑和数据的解耦合，通过普通权限和衍生权限的划分，实现了权限系统和功能模块权限判定的解耦合，该结构具有良好的可扩展性。
【参考文献】
[1]Osborn S,Sandhu R.Configuring Role to Based Access Control to Enforce Mandatory and Discretionary Access Control Policies.ACM Transactions on Information and System Security,2000, 3(2),123-132.
[2]Joseph W Yoder.Connecting Business Objects to Relational Database [EB/OL].
https://www.joeyoder.com/~yoder/papers/patterns/PersistentObject/Persista.pdf.2005.
[3]宛延闽. 面向对象分析和设计.北京:清华大学出版社, 2001.
作者简介：张恩瑞，男，在读工程硕士，主要研究MIS中的权限设计
