用户权限系统设计方案

用户权限系统设计方案

钟峰·2004年10月
[版本：1.0.0]

摘要　　本文介绍一个应用于企业应用通用的用户权限系统的设计框架，其设计思想与主要文档来源自 SunWu Software Studio 的 iSecurityManager® 产品。本指南适用于体系结构设计人员和开发人员。

目录 简介 用户与角色 动作定义 应用模块 授权 总结 链接资源

简介　　安全始终是可信赖的企业应用的基石。
　　在企业应用中，通常需要控制用户对业务操作的权限管理与控制。稍加分析不难发现这会涉及到这三个对象：用户/角色、动作/操作、授权状态，进一步分析，我们可发现“动作/操作”通常是针对某个特定的对象，譬如 『新增』动作可对应于『采购申请单』也可对应于『销售出库单』等，这些动作对应的对象我们将其称之为“应用模块”。
　　至此，用户权限系统中的基本逻辑显形：谁（用户/角色）对什么（应用模块）是否具有某项操作（动作）的授权（授权状态：授予-Grant、拒绝-Deny、继承-Revoke）。

用户与角色　　使用权限的基本单位，角色是具有一组相同授权的用户的交集。用户与用户之间没有互相隶属的关系，它只可以隶属于角色，角色可以隶属于另一角色，并且可具有多重隶关系。
　　用户或角色通常具有以下属性： 编号，在系统中唯一。 名称，在系统中唯一。 用户口令（角色无此属性） 　　当然，在实际的商业应用中，可能还需要更多的属性来描述特定的业务需求。如在 iSecurityManager® 中用户和角色的信息就有如下：

图一：角色信息

图二：用户信息

　　有了用户和角色对象，还必须有一个描述他们之间隶属关系的对象，这样的对象我们称之为“成员关系(Member)”，通常它可能有如下属性：
用户编号 角色编号 　　该“用户编号”和“角色编号”组合唯一约束，这里的“用户编号”可能是一个用户对象的编号，也可能是一个角色对象的编号，而“角色编号”则始终只能对应一个角色对象的编号。一个成员关系对象表示某个用户或角色隶属于另个角色。在 iSecurityManager® 中可能有如下界面表示：

图三：用户/角色成员关系

　　在 iSecurityManager® 中通过『成员设置』窗口来设置任何一个用户或角色（系统固定用户和角色除外）所隶属于的角色，也可以通过『角色属性』窗口来设置所属于当前角色的直接下级成员。

动作定义　　在涉及数据库操作的应用中，四个基本操作是“查看(Select)”、“删除(Delete)”、“新增(Insert)”以及“更新(Update)”。在一个企业应用中当然还会有更多其他的操作，尽管这些操作可能最终都基于这四个基本操作，也可能是其他的非数据操作，而我们始终无法在刚开始就完全固定这些可能的操作，为此，必须能让系统开发人员根据每个具体的应用模块来定义其所属的特定的动作/操作。
　　动作/操作通常具有以下属性： 名称，在系统中唯一。 备注，描述动作/操作。 　　在 iSecurityManager® 中“动作定义”的信息就有如下：

图四：动作定义

　　事实上，有些动作是需要针对具体的数据实例的，譬如“查看”、“删除”和“更新”等，这种对数据实例级别的控制比针对“应用模块”级的控制要更精细。譬如，某个用户能进行对【采购申请单】的各项操作，他应该能查看他刚填写的单据并进行某些适当的修改，但是他却不应该看到其他人填写的数据。那么，这种粗粒度的权限设置显然无法控制数据级的访问，在 iSecurityManager® 中，专门使用“流程控制”的方案和技术来达致更细粒度的对数据实例级的访问和控制。

应用模块　　应用模块通常是指对应于企业应用中的某种类型的业务单据，譬如 ERP 系统中的【采购申请单】、【销售出库单】、【客户基础资料】等，这些业务单据可能对应一或多张数据库表。如果从面向对象(Object Oriented)的视角去看，似乎可以将本文中所描述的这些概念理解成这样：“应用模块”是类，“动作/操作”则是类的方法，而“应用模块”对应的数据库表（表结构）则是类的属性，表中的这些数据/记录就是类的实例了。
　　在定义规划系统中的“应用模块”时，通常还需要指定某个“应用模块”可能具有的“动作/操作”，而这些“动作/操作”由『动作定义』中进行了定义。注意：应用模块是系统中的一种逻辑组织单位。
　　应用模块通常具有以下属性： 名称，在系统中唯一。 标题，描述动作/操作。 动作列表，表示该应用模块所可能具有的所有操作。 　　在 iSecurityManager® 中“应用模块”的信息就有如下：

图五：应用模块定义

授权　　顾名思义，授权是指用户/角色能对哪些应用模块中的某些操作（动作）是否具有执行的许可。这里的“是否具有执行的许可”实际上指的是授权的三种状态：授予-Grant、拒绝-Deny、继承-Revoke。
授予：用户/角色对某个应用模块的某项操作具有执行的权力。 拒绝：用户/角色对某个应用模块的某项操作没有执行的权力。 继承：用户/角色对某个应用模块的某项操作是否具有执行的权力要取决于它的父角色的授权定义。 　　如果对某个角色授予某项权力，其下属的用户或角色是可以覆盖该项授权定义的。默认情况下，采用就近优先、拒绝优先的原则。
　　在 iSecurityManager® 中“授权设置”的信息如下所示：

图六：权限设置

总结　　通常“应用模块”和“动作定义”是由系统开发商在系统设计、开发阶段就定义好了，在系统交付给用户使用后就不再对此更改了（当然这也不是绝对的，不是吗？）。

　　至此，有关用户权限的各项设置、定义都完成了，事实上，这并不会立即为你的应用系统带来任何安全保障，这只是一堆关于用户和授权定义的设置数据而已，还必须在应用系统中去应用这些设置数据并根据其定义的控制逻辑以对业务数据进行控制。如何利用这些用户授权数据来控制应用系统对业务数据的访问，有很多不同的解决方案，但是我认为建立一个中间数据存储层来统一所有客户端对数据源的存储访问是个不错的主意，并在这个数据访问层中应用安全设置来对业务数据的各种访问进行授权验证和控制，这样就可以统一各种客户端对数据存储的安全应用（事实上 iSecurityManager® 也正是如此处理这个问题的）。

链接资源　　钟峰(Popeye Zhong)目前是 深圳恒泰丰科技公司 的.NET开发组的架构设计人员。他曾经使用 C 语言做过图形程序设计，在相当长的一段时期内从事 COM/COM+ 组件的开发和设计工作，并且短暂的做过 Lotus/Notes 和 Dialogic 语音卡程序的开发，从2003年初开始使用.NET这个充满趣味和挑战的开发平台。感兴趣的除了企业应用架构设计、组件开发、安全、图像处理外还对汽车和枪械模型有浓厚的兴趣。如果希望与他联系，可访问 http://blog.csdn.net/SW515 或者EMail [email protected] 。

相关文章：《安全之道：加密与数字签名》

[1] 企业应用：企业应用包括 工资单、患者记录、发货跟踪、成本分析、信誉评估、保险、供应链、生产管理、记帐、客户服务以及外币交易等。企业应用不包括车辆加油、文字处理、电梯控制、电话交换机、操作系统、编译器以及电子游戏等。【引用于《企业应用架构模式》Martin Fowler 著】

本文地址：http://com.8s8s.com/it/it14266.htm