基于授权和角色的访问控制的设计和实现（一）

摘要<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

访问控制是软件安全性重要的部分，本文探讨了采用角色和授权来实现访问控制的一种方法。本文侧重于访问控制从设计到实现的过程。

一   领域建模

1        安全对象

在一个管理系统中需要限制用户的地方都是“安全对象”。安全对象有个特点：一旦你的系统设计完毕，则其所有的安全对象就唯一确定了。它不能在运行期间随意调整(相对于用户、角色)，所以必须在设计期间仔细找出并定义安全对象。安全对象的定义根据不同的项目、不同的安全要求是不同的，定义安全对象时应该与客户一起进行。
安全对象的分类基本上可以从两个视角来入手：按结构分类，如一个管理系统可以分为多个子系统，而每个子系统又可分为多个模块(窗体、页面)，每个模块又有许多字段；按行为分类，如浏览、新增、修改、删除、审核等。如果仅从一个角度来唯一确定安全对象都是不完整的，一个较好的方法是先按结构找出用户要操作的最小的结构安全对象，然后对每个对象找出其可能的操作安全对象，每个操作安全对象应该被看成相应结构安全对象的子对象。为了简化模型我们可以增加一个规则：操作安全对象不能有子操作安全对象。

2        访问者

在确定了安全对象之后下一步是确定谁来访问它们，以及它们怎样被访问。在实际的系统中会有一个安全对象的代码中调用另外一个安全对象方法的情况，但是这些行为都是在有用户处于与应用程序会话中这样的情形中发生的。这个“情形”在分布式应用程序中有一个比较形象的术语：上下文(Context)。在基于角色的访问控制系统中，这个上下文除了当前的用户之外还包括这个用户当前的角色。这样能访问安全对象的可以是用户和角色，由于它们在访问安全对象时使用统一的接口，所以我们可以把它们提炼出一个公共的父类——访问者。
访问者的确定一般是在程序部署时由管理员或系统安全员来完成的，所以在设计时要考虑其通用性和可扩展性。

3        授权

很明显“用户—角色”和“访问者—安全对象”都是多对多的关系，所以很自然它们之间都需要一个关联对象来处理这些对应关系。在“访问者—安全对象”关系中，如果要让访问者可以访问一个安全对象，只需将相应的安全对象授权给该访问者就可以了。
在授权模式中，因为参与授权双方均可能存在拥有子对象的情况。这里引出的问题是：授权双方的子对象是否自动拥有该授权呢(或者说参与授权对象的子对象能否继承父对象的授权)？无论是否使用继承授权都是一个好的答案，使用继承可以使用较少的授权来表示较多的允许(更方便)，而不使用继承则可以清晰地唯一定义授权(更有效)。

4        验证规则

上述授权中隐藏的一个规则是：授权只表示允许。在实际安全管理中，管理员或者安全员可能需要将安全对象只授给拥有某个角色的其中一部分用户，另外管理员可能会指定一个授权只在指定的时间段有效。这些都是系统的安全规则，套用流行的术语就是企业的业务逻辑。所以只使用简单的“授权表示允许”的规则显然不能满足现在系统日益复杂的安全需求。
我们在这里抽象出一个验证规则对象。根据验证规则对象我们可以得到“访问者”访问一个“安全对象”是：被允许的、被拒绝的、还是不能确定的。一个授权可能会有一个以上的有效性规则对象，对一个授权的每一条有效性规则进行验证会有相互冲突可能性。一个解决冲突的有效规则是：拒绝优先，最终不能确定的应视同拒绝。

5        总结

经过简单的领域分析，我们可以得出一个较完整的领域模型，见图1：
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />


图1 领域模型