《用户权限系统设计方案》由会员分享，可在线阅读，更多相关《用户权限系统设计方案（21页珍藏版）》请在金锄头文库上搜索。
1、 用户权限系统设计方案摘要本文介绍一个应用于企业应用通用的用户权限系统的设计框架，其设计思想与主要文档来源自 SunWu Software Studio 的 iSecurityManager 产品。本指南适用于体系结构设计人员和开发人员。目录简介用户与角色动作定义应用模块授权总结链接资源简介安全始终是可信赖的企业应用的基石。在企业应用中，通常需要控制用户对业务操作的权限管理与控制。稍加分析不难发现这会涉及到这三个对象：用户/角色、动作/操作、授权状态，进一步分析，我们可发现“动作/操作”通常是针对某个特定的对象，譬如 新增动作可对应于采购申请单也可对应于销售出库单等，这些动作对应的对象我们将其
2、称之为“应用模块”。至此，用户权限系统中的基本逻辑显形：谁（用户/角色）对什么（应用模块）是否具有某项操作（动作）的授权（授权状态：授予-Grant、拒绝-Deny、继承-Revoke）。用户与角色使用权限的基本单位，角色是具有一组相同授权的用户的交集。用户与用户之间没有互相隶属的关系，它只可以隶属于角色，角色可以隶属于另一角色，并且可具有多重隶关系。用户或角色通常具有以下属性：编号，在系统中唯一。名称，在系统中唯一。用户口令（角色无此属性）当然，在实际的商业应用中，可能还需要更多的属性来描述特定的业务需求。如在 iSecurityManager 中用户和角色的信息就有如下：图一：角色信息图二
3、：用户信息有了用户和角色对象，还必须有一个描述他们之间隶属关系的对象，这样的对象我们称之为“成员关系(Member)”，通常它可能有如下属性：用户编号角色编号该“用户编号”和“角色编号”组合唯一约束，这里的“用户编号”可能是一个用户对象的编号，也可能是一个角色对象的编号，而“角色编号”则始终只能对应一个角色对象的编号。一个成员关系对象表示某个用户或角色隶属于另个角色。在 iSecurityManager 中可能有如下界面表示：图三：用户/角色成员关系在 iSecurityManager 中通过成员设置窗口来设置任何一个用户或角色（系统固定用户和角色除外）所隶属于的角色，也可以通过角色属性窗口来
4、设置所属于当前角色的直接下级成员。动作定义在涉及数据库操作的应用中，四个基本操作是“查看(Select)”、“删除(Delete)”、“新增(Insert)”以及“更新(Update)”。在一个企业应用中当然还会有更多其他的操作，尽管这些操作可能最终都基于这四个基本操作，也可能是其他的非数据操作，而我们始终无法在刚开始就完全固定这些可能的操作，为此，必须能让系统开发人员根据每个具体的应用模块来定义其所属的特定的动作/操作。动作/操作通常具有以下属性：名称，在系统中唯一。备注，描述动作/操作。在 iSecurityManager 中“动作定义”的信息就有如下：图四：动作定义事实上，有些动作是需要
5、针对具体的数据实例的，譬如“查看”、“删除”和“更新”等，这种对数据实例级别的控制比针对“应用模块”级的控制要更精细。譬如，某个用户能进行对【采购申请单】的各项操作，他应该能查看他刚填写的单据并进行某些适当的修改，但是他却不应该看到其他人填写的数据。那么，这种粗粒度的权限设置显然无法控制数据级的访问，在 iSecurityManager 中，专门使用“流程控制”的方案和技术来达致更细粒度的对数据实例级的访问和控制。应用模块应用模块通常是指对应于企业应用中的某种类型的业务单据，譬如 ERP 系统中的【采购申请单】、【销售出库单】、【客户基础资料】等，这些业务单据可能对应一或多张数据库表。如果从面
6、向对象(Object Oriented)的视角去看，似乎可以将本文中所描述的这些概念理解成这样：“应用模块”是类，“动作/操作”则是类的方法，而“应用模块”对应的数据库表（表结构）则是类的属性，表中的这些数据/记录就是类的实例了。在定义规划系统中的“应用模块”时，通常还需要指定某个“应用模块”可能具有的“动作/操作”，而这些“动作/操作”由动作定义中进行了定义。注意：应用模块是系统中的一种逻辑组织单位。应用模块通常具有以下属性：名称，在系统中唯一。标题，描述动作/操作。动作列表，表示该应用模块所可能具有的所有操作。在 iSecurityManager 中“应用模块”的信息就有如下：图五：应用模
7、块定义授权顾名思义，授权是指用户/角色能对哪些应用模块中的某些操作（动作）是否具有执行的许可。这里的“是否具有执行的许可”实际上指的是授权的三种状态：授予-Grant、拒绝-Deny、继承-Revoke。授予：用户/角色对某个应用模块的某项操作具有执行的权力。拒绝：用户/角色对某个应用模块的某项操作没有执行的权力。继承：用户/角色对某个应用模块的某项操作是否具有执行的权力要取决于它的父角色的授权定义。如果对某个角色授予某项权力，其下属的用户或角色是可以覆盖该项授权定义的。默认情况下，采用就近优先、拒绝优先的原则。在 iSecurityManager 中“授权设置”的信息如下所示：图六：权限设置
8、总结通常“应用模块”和“动作定义”是由系统开发商在系统设计、开发阶段就定义好了，在系统交付给用户使用后就不再对此更改了（当然这也不是绝对的，不是吗？）。至此，有关用户权限的各项设置、定义都完成了，事实上，这并不会立即为你的应用系统带来任何安全保障，这只是一堆关于用户和授权定义的设置数据而已，还必须在应用系统中去应用这些设置数据并根据其定义的控制逻辑以对业务数据进行控制。如何利用这些用户授权数据来控制应用系统对业务数据的访问，有很多不同的解决方案，但是我认为建立一个中间数据存储层来统一所有客户端对数据源的存储访问是个不错的主意，并在这个数据访问层中应用安全设置来对业务数据的各种访问进行授权验证和
9、控制，这样就可以统一各种客户端对数据存储的安全应用（事实上 iSecurityManager 也正是如此处理这个问题的）。权限设计数据库结构表 1 -权限许可 1 create table res_permission 1 ( 1 roleid INTEGER, 1 resourceid varchar2(30), 1 operationid integer, 1 primary key(roleid,resourceid,operationid) 1 ) 1 1 1 -角色定义 1 create table res_role 1 ( 1 roleid INTEGER, 1 rolename
10、varchar2(30), 1 roledesc varchar2(100), 1 primary key(roleid) 1 ) 1 1 -角色权限 1 create table res_userrole 1 ( 1 roleid INTEGER, 1 userid varchar2(30),-用户名 1 primary key(roleid,userid) 1 ) 1 1 -资源 1 create table res_resource 1 ( 1 resourceid varchar2(20), 1 resourcename varchar2(30), 1 resourcedesc var
11、char2(100), 1 primary key(resourceid) 1 ) 1 -操作信息 1 create table res_operation 1 ( 1 operationid varchar2(20), 1 operationname varchar2(30), 1 operationdesc varchar2(100), 1 primary key(operationid) 1 ) 1 -res_operation 表的序列号 1 create sequence res_operation_seq; 1 -res_role 表的序列 1 create sequence re
12、s_role_seq; 1 -建立soperationid与sroleid两个序列分别用来产生Operation表与Role表的ID列 1 create sequence soperationid increment by 1 start with 1 nomaxvalue minvalue 1; 1 create sequence sroleid increment by 1 start with 1 nomaxvalue minvalue 1; 1 -表设计的原理-根据交叉法来匹配权限-1:根据用户表中的用户id关联到res_userrole的userid，然后再关联到res_role，查
13、出用户对应的所有权限，存放到list中-2:根据资源和操作查询出用户可以操作的所有许可res_permission，存放到list中-3:通过同时遍历两个list，查询出是否存在交叉，如果存在就是有权限，否则为无权限四海同志的文章中有这样一句话：“传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。似乎他的那个权限设计也没有能够解决资源重用的问题。当然，如果它把资源文件分别存放在不通的文件夹中，通过url来根据权限来判断那就另当别论了。我这个人比较懒，总是想用一个通用的方法，放在哪里都合适，因此在数据库
14、的设计上费了一番脑筋了。其实，很多的权限管理系统都不太一样，因此，很多开发者开发出来的权限管理系统放在别的地方，就不一定合适了，往往需要重新开发，权限管理系统的结构不能变，变的仅仅是数据。在这样的一个思想的指导下，我们就想法让我们的结构不要变，尽可能的通用，其实结构在哪里，还是体现在数据库上了。四海同志说：“权限”，“组”和“人”。而这三种元素可以任意添加，彼此之间不受影响。而我却认为，一个完整的权限管理系统应该包括：用户、角色、模块、资源这四个部分，在数据库的表设计上，这四张表叫做权限管理系统的实体表，只要把这四个实体表做出来，权限管理系统的架构就搭建完整了，这样的权限管理系统翻译成中文那就是：权限管理系统是判断（可能用判断这个词不是很准确）用户或角色对什么资源是否有什么功能的这样一个系统。这样设计出来的权限管理系统通用性、扩展性才够强，系统足够完整。四张实体表做好了，就意味着架构搭建好了，那么逻辑关系怎么办呢？我当时设计的时候用另外的
