参考文献
1. MSDN 文档
2. MS Authorization and Profile Application Block Help 文档
1. 概述
在应用程序设计中，常常需要根据不同用户控制其在程序中的行为。例如：管理员、经理、员工在程序中的访问级别存在差异，而一个用户可以扮演多个角色。用户访问受保护资源或执行受保护操作的能力称为权限，可表述为“判断WHO对WHAT(WHICH)进行HOW的操作”的逻辑表达式。
现有的权限认证主要基于两种机制：ACL（访问控制列表）和基于角色的控制。
ACL为安全对象建立访问控制列表（DACLS）。通过比较用户的权限是否存在于列表中，决定用户可以访问资源。
基于角色（Role-based）通过将系统按角色划分权限。当用户关联到某个角色，将自动获得该角色所拥有的权限。
在企业应用方面，基于角色的控制方法，由于减小了授权管理的复杂性，易于操作，具有较好的前景。
值得注意的是，权限并不是简单的判定过程。权限的检查常常需要应用业务逻辑。例如：合同只能被其创建者删除，同组用户可以修改，授权用户可以查看。通常，与权限控制对象的实例相关的称为细粒度权限，而只与对象类型关联的称为粗粒度权限。
1. 设计目标
权限系统模块提供基本架构支持基于角色方式的授权。
1. 向系统中的用户授权
2. 支持角色的继承
3. 支持权限系统的多种存储方式
4. 支持业务逻辑验证
5. 具有较好的扩展性和性能
2. 分析
2.1. 权限系统的工作流程
总体上讲，权限系统的工作由下列过程组成：
① 权限系统初始化
② 权限系统接收用户对资源的访问请求
③ 权限系统根据用户具有的权限，返回true或false
④ 最后，权限系统释放其资源，销毁实例。
2.2. 权限系统的对象
n 资源
资源是权限系统的保护对象。资源可以是某个实体，如文件系统中的文件；也可以是概念。在应用程序中，资源更多以模块划分。
资源间存在嵌套关系。如：现金流量表属于财务报表。
对资源的访问方式称为操作。显然，资源可以具有多种操作。如：合同具有录入、查看、修改、删除、执行、审核、打印等不同操作。
操作间存在重叠关系，比如对合同审核者当然可以查看合同。
概念模型如下：
n 用户和角色
用户是权限系统的访问实体。角色是具有某类权限集的用户的统称。角色之间存在继承关系，比如财务主管同时也是财务人员。
概念模型如下：
值得注意的是，权限与角色并不存在一致性。如：某用户希望拥有其角色外的权限；某角色希望屏蔽属于其类别的某个（些）用户的权限。
概念模型扩展如下：
① 用户可以直接赋权限
② 角色与受控列表关联。受控列表即存储角色中某些用户禁止对角色中允许的资源进行访问列表。
2.3. 权限系统的模块
n 资源管理
系统中的受控资源通常都是可确定的。如果资源发生变化，常意味着代码的更迭（包含资源分配与验证部分）。因此，在系统中的受控资源在程序运行态时不可变的前提下，资源管理的功能较为简单：
a) 获取系统中所有资源列表
b) 根据资源(操作)标识，取得资源信息。
n 权限管理
权限管理是系统中的关键部分，决定权限分配到实体对象中的过程。
权限管理的功能如下：
a) 增加、删除、更新用户或角色对资源访问的权限。
b) 获取系统中某用户或角色所赋有的所有权限。
c) 获取系统中某用户或角色对某种资源（操作）的权限
d) 增加、删除角色受控列表条目
值得注意的是用户权限是用户所具有的角色权限和其本身所赋予的权限的交集。因此在权限对象中设置角色用户标志加以区分。
n 权限检查
权限检查是系统中的应用部分。 权限检查包含业务逻辑检查。
① 权限检查使用权限管理器的功能。
② 业务逻辑检查共发生两次。一次在权限检查之前，一次在权限检查之后。权限检查之前的业务逻辑检查可以直接返回结果，而不用再进行权限检查。
3. 权限系统架构
权限系统设计为可扩展性结构。使用Provider接口用于权限模型与数据存储间的交互。通过实现自定义的Provider，经过配置入口插入权限系统中。
配置文件以XML文件为主流格式。Provider接口定义如下：
Element为XML文件元素类型
