用户权限系统设计方案

用户权限系统设计方案摘要本文介绍一个应用于企业应用通用的用户权限系统的设计框架，其设计思想与主要文档来源自SunWuSoftwareStudio的iSecurityManager®产品。本指南适用于体系结构设计人员和开发人员。目录简介用户与角色动作定义应用模块授权总结链接资源简介安全始终是可信赖的企业应用的基石。在企业应用中，通常需要控制用户对业务操作的权限管理与控制。稍加分析不难发现这会涉及到这三个对象：用户/角色、动作/操作、授权状态，进一步分析，我们可发现“动作/操作”通常是针对某个特定的对象，譬如『新增』动作可对应于『采购申请单』也可对应于『销售出库单』等，这些动作对应的对象我们将其称之为“应用模块”。至此，用户权限系统中的基本逻辑显形：谁（用户/角色）对什么（应用模块）是否具有某项操作（动作）的授权（授权状态：授予-Grant、拒绝-Deny、继承-Revoke）。用户与角色使用权限的基本单位，角色是具有一组相同授权的用户的交集。用户与用户之间没有互相隶属的关系，它只可以隶属于角色，角色可以隶属于另一角色，并且可具有多重隶关系。用户或角色通常具有以下属性：编号，在系统中唯一。名称，在系统中唯一。用户口令（角色无此属性）当然，在实际的商业应用中，可能还需要更多的属性来描述特定的业务需求。如在iSecurityManager®中用户和角色的信息就有如下：图一：角色信息图二：用户信息有了用户和角色对象，还必须有一个描述他们之间隶属关系的对象，这样的对象我们称之为“成员关系(Member)”，通常它可能有如下属性：用户编号角色编号该“用户编号”和“角色编号”组合唯一约束，这里的“用户编号”可能是一个用户对象的编号，也可能是一个角色对象的编号，而“角色编号”则始终只能对应一个角色对象的编号。一个成员关系对象表示某个用户或角色隶属于另个角色。在iSecurityManager®中可能有如下界面表示：图三：用户/角色成员关系在iSecurityManager®中通过『成员设置』窗口来设置任何一个用户或角色（系统固定用户和角色除外）所隶属于的角色，也可以通过『角色属性』窗口来设置所属于当前角色的直接下级成员。动作定义在涉及数据库操作的应用中，四个基本操作是“查看(Select)”、“删除(Delete)”、“新增(Insert)”以及“更新(Update)”。在一个企业应用中当然还会有更多其他的操作，尽管这些操作可能最终都基于这四个基本操作，也可能是其他的非数据操作，而我们始终无法在刚开始就完全固定这些可能的操作，为此，必须能让系统开发人员根据每个具体的应用模块来定义其所属的特定的动作/操作。动作/操作通常具有以下属性：名称，在系统中唯一。备注，描述动作/操作。在iSecurityManager®中“动作定义”的信息就有如下：图四：动作定义事实上，有些动作是需要针对具体的数据实例的，譬如“查看”、“删除”和“更新”等，这种对数据实例级别的控制比针对“应用模块”级的控制要更精细。譬如，某个用户能进行对【采购申请单】的各项操作，他应该能查看他刚填写的单据并进行某些适当的修改，但是他却不应该看到其他人填写的数据。那么，这种粗粒度的权限设置显然无法控制数据级的访问，在iSecurityManager®中，专门使用“流程控制”的方案和技术来达致更细粒度的对数据实例级的访问和控制。应用模块应用模块通常是指对应于企业应用中的某种类型的业务单据，譬如ERP系统中的【采购申请单】、【销售出库单】、【客户基础资料】等，这些业务单据可能对应一或多张数据库表。如果从面向对象(ObjectOriented)的视角去看，似乎可以将本文中所描述的这些概念理解成这样：“应用模块”是类，“动作/操作”则是类的方法，而“应用模块”对应的数据库表（表结构）则是类的属性，表中的这些数据/记录就是类的实例了。在定义规划系统中的“应用模块”时，通常还需要指定某个“应用模块”可能具有的“动作/操作”，而这些“动作/操作”由『动作定义』中进行了定义。注意：应用模块是系统中的一种逻辑组织单位。应用模块通常具有以下属性：名称，在系统中唯一。标题，描述动作/操作。动作列表，表示该应用模块所可能具有的所有操作。在iSecurityManager®中“应用模块”的信息就有如下：图五：应用模块定义授权顾名思义，授权是指用户/角色能对哪些应用模块中的某些操作（动作）是否具有执行的许可。这里的“是否具有执行的许可”实际上指的是授权的三种状态：授予-Grant、拒绝-Deny、继承-Revoke。授予：用户/角色对某个应用模块的某项操作具有执行的权力。拒绝：用户/角色对某个应用模块的某项操作没有执行的权力。继承：用户/角色对某个应用模块的某项操作是否具有执行的权力要取决于它的父角色的授权定义。如果对某个角色授予某项权力，其下属的用户或角色是可以覆盖该项授权定义的。默认情况下，采用就近优先、拒绝优先的原则。在iSecurityManager®中“授权设置”的信息如下所示：图六：权限设置总结通常“应用模块”和“动作定义”是由系统开发商在系统设计、开发阶段就定义好了，在系统交付给用户使用后就不再对此更改了（当然这也不是绝对的，不是吗？）。至此，有关用户权限的各项设置、定义都完成了，事实上，这并不会立即为你的应用系统带来任何安全保障，这只是一堆关于用户和授权定义的设置数据而已，还必须在应用系统中去应用这些设置数据并根据其定义的控制逻辑以对业务数据进行控制。如何利用这些用户授权数据来控制应用系统对业务数据的访问，有很多不同的解决方案，但是我认为建立一个中间数据存储层来统一所有客户端对数据源的存储访问是个不错的主意，并在这个数据访问层中应用安全设置来对业务数据的各种访问进行授权验证和控制，这样就可以统一各种客户端对数据存储的安全应用（事实上iSecurityManager®也正是如此处理这个问题的）。权限设计数据库结构表--权限许可createtableres_permission(roleidINTEGER,resourceidvarchar2(30),operationidinteger,primarykey(roleid,resourceid,operationid))--角色定义createtableres_role(roleidINTEGER,rolenamevarchar2(30),roledescvarchar2(100),primarykey(roleid))--角色权限createtableres_userrole(roleidINTEGER,useridvarchar2(30),--用户名primarykey(roleid,userid))--资源createtableres_resource(resourceidvarchar2(20),resourcenamevarchar2(30),resourcedescvarchar2(100),primarykey(resourceid))--操作信息createtableres_operation(operationidvarchar2(20),operationnamevarchar2(30),operationdescvarchar2(100),primarykey(operationid))--res_operation表的序列号createsequenceres_operation_seq;--res_role表的序列createsequenceres_role_seq;--建立soperationid与sroleid两个序列分别用来产生Operation表与Role表的ID列createsequencesoperationidincrementby1startwith1nomaxvalueminvalue1;createsequencesroleidincrementby1startwith1nomaxvalueminvalue1;--表设计的原理--根据交叉法来匹配权限--1:根据用户表中的用户id关联到res_userrole的userid，然后再关联到res_role，查出用户对应的所有权限，存放到list中--2:根据资源和操作查询出用户可以操作的所有许可res_permission，存放到list中--3:通过同时遍历两个list，查询出是否存在交叉，如果存在就是有权限，否则为无权限四海同志的文章中有这样一句话：“传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。似乎他的那个权限设计也没有能够解决资源重用的问题。当然，如果它把资源文件分别存放在不通的文件夹中，通过url来根据权限来判断那就另当别论了。我这个人比较懒，总是想用一个通用的方法，放在哪里都合适，因此在数据库的设计上费了一番脑筋了。其实，很多的权限管理系统都不太一样，因此，很多开发者开发出来的权限管理系统放在别的地方，就不一定合适了，往往需要重新开发，权限管理系统的结构不能变，变的仅仅是数据。在这样的一个思想的指导下，我们就想法让我们的结构不要变，尽可能的通用，其实结构在哪里，还是体现在数据库上了。四海同志说：“权限”，“组”和“人”。而这三种元素可以任意添加，彼此之间不受影响。而我却认为，一个完整的权限管理系统应该包括：用户、角色、模块、资源这四个部分，在数据库的表设计上，这四张表叫做权限管理系统的实体表，只要把这四个实体表做出来，权限管理系统的架构就搭建完整了，这样的权限管理系统翻译成中文那就是：权限管理系统是判断（可能用判断这个词不是很准确）用户或角色对什么资源是否有什么功能的这样一个系统。这样设计出来的权限管理系统通用性、扩展性才够强，系统足够完整。四张实体表做好了，就意味着架构搭建好了，那么逻辑关系怎么办呢？我当时设计的时候用另外的4张表来存储他们之间的逻辑关系，总共8张表，四张实体表，四张逻辑关系表。其它的权限管理系统可能少于8张表，一般通用性不会太好的。通常都是在完整的基础上做了下变化，有的利用继承来做，有的利用位运算，还有的虽然不通用，但是也是充分利用了自身的特点，一般都会少于8张表，但是一般翻译成汉语都不完整。通常为：用户对资源是否有什么功能、用户或角色对资源是否有权限等等。。。。切记，通用的权限管理系统无论是用户、角色、模块、资源哪个方面，都可以在不改变架构的条件下去动态的扩展，改变的仅仅是数据，而只要有这个思想，再结合自身项目的特点，相信设计和开发各种各样不通的权限管理系统不会有问题的用户权限管理2008-01-03通用权限管理系统设计篇（一）一．引言因为做过的一些系统的权限管理的功能虽然在逐步完善，但总有些不尽人意的地方，总想抽个时间来更好的思考一下权限系统的设计。权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。二．设计目标设计一个灵活、通用、方便的权限管理系统。在这个系统中，我们需要对系统的所有资源进行权限控制，那么系统中的资源包括哪些呢？我们可以把这些资源简单概括为静态资源（功能操作、数据列）和动态资源（数据），也分别称为对象资源和数据资源，后者是我们在系统设计与实现中的叫法。系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮、数据显示的列以及各种行级数据进行权限的操控。三．相关对象及其关系大概理清了一下权限系统的相关概念，如下所示：1.权限系统的所有权限信息。权限具有上下级关系，是一个树状的结构。下面来看一个例子系统管理用户管理查看用户新增用户修改用户删除用户对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例