通用权限管理系统设计篇.doc

1、通用权限管理系统设计篇一引言 因为做过的一些系统的权限管理的功能虽然在逐步完善，但总有些不尽人意的地方，总想抽个时间来更好的思考一下权限系统的设计。权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。二设计目标设计一个灵活、通用、方便的权限管理系统。在这个系统中，我们需要对系统的所有资源进行权限控制，那么系统中的资源包括哪些呢？我们可以把这些资源简单概括为静态资源（功能操作、数据列）和动态资源（数据），也分别称为对象资源和数据资源，后者是我们在系统设计

2、与实现中的叫法。系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮、数据显示的列以及各种行级数据进行权限的操控。三相关对象及其关系大概理清了一下权限系统的相关概念，如下所示：1. 权限系统的所有权限信息。权限具有上下级关系，是一个树状的结构。下面来看一个例子系统管理用户管理查看用户新增用户修改用户删除用户对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。2. 用户应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于

3、0n 个角色，可属于 0n 个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是 n 对 n 的关系。3. 角色为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。4. 组为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际情况中，我们知道，组也可以具有自己的角色信息、权限信息。这让我想到我们的 QQ 用户群

4、，一个群可以有多个用户，一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ 群也可以具有自己的角色信息，例如普通群、高级群等。针对上面提出的四种类型的对象，让我们通过图来看看他们之间的关系。有上图中可以看出，这四者的关系很复杂，而实际的情况比这个图还要复杂，权限、角色、组都具有上下级关系，权限管理是应用系统中比较棘手的问题，要设计一个通用的权限管理系统，工作量也着实不小。当然对于有些项目，权限问题并不是那么复杂。有的只需要牵涉到权限和用户两种类型的对象，只需要给用户分配权限即可。在另一些情况中，引入了角色对象，例如基于角色的权限系统， 只需要给角色分配权限，用户都隶属于角

5、色，不需要单独为用户分配角色信息。在下一篇中，我们将讲述权限管理的数据库设计等内容。欢迎各位拍砖或给出宝贵意见。国庆前整的通用权限设计的数据库初步设计部分，现在贴上来。理清了对象关系之后，让我们接着来进行数据库的设计。在数据库建模时，对于 N 对 N 的关系，一般需要加入一个关联表来表示关联的两者的关系。初步估计一下，本系统至少需要十张表，分别为：权限表、用户表、角色表、组表、用户权限关联表、用户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。当然还可能引出一些相关的表。下面让我们在 PowerDesigner 中画出各表吧。各表及其关系如下：1. 用户表用户表（TUs

6、er ）字段名称 字段 类型 备注记录标识 tu_id bigint pk, not null所属组织 to_id bigint fk, not null登录帐号 login_name varchar(64) not null用户密码 password varchar(64) not null用户姓名 vsername varchar(64) not null手机号 mobile varchar(20)电子邮箱 email varchar(64)创建时间 gen_time datetime not null登录时间 login_time datetime上次登录时间 last_login_ti

7、me datetime登录次数 count bigint not null2. 角色表角色表（TRole）字段名称 字段 类型 备注角色 ID tr_id bigint pk, not null父级角色 ID parent_tr_id bigint not null角色名称 role_name varchar(64) not null创建时间 gen_time datetime not null角色描述 description varchar(200)3. 权限表权限表（TRight）字段名称 字段 类型 备注权限 ID tr_id bigint pk, not null父权限 parent_

8、tr_id bigint not null权限名称 right_name varchar(64) not null权限描述 description varchar(200)4. 组表组表（TGroup）字段名称 字段 类型 备注组 ID tg_id bigint pk, not null组名称 group_name varchar(64) not null父组 parent_tg_id bigint not null创建时间 gen_time datetime not null组描述 description varchar(200)5. 角色权限表角色权限表（TRoleRightRelatio

9、n）字段名称 字段 类型 备注记录标识 trr_id bigint pk, not null角色 Role_id bigint fk, not null权限 right_id bigint fk, not null权限类型 right_type int not null（0:可访问，1:可授权）6. 组权限表组权限表（TGroupRightRelation ）字段名称 字段 类型 备注记录标识 tgr_id bigint pk, not null组 tg_id bigint fk, not null权限 tr_id bigint fk, not null权限类型 right_type int

10、not null（0:可访问，1:可授权）7. 组角色表组角色表（TGroupRoleRelation）字段名称 字段 类型 备注记录标识 tgr_id bigint pk, not null组 tg_id bigint fk, not null角色 tr_id bigint pk, not null8. 用户权限表用户权限表（TUserRightRelation）字段名称 字段 类型 备注记录标识 tur_id bigint pk, not null用户 tu_id bigint fk, not null权限 tr_id bigint fk, not null权限类型 right_type

11、int not null（0:可访问，1:可授权）9. 用户角色表用户角色表（TUserRoleRelation）字段名称 字段 类型 备注记录标识 tur_id bigint pk, not null用户 tu_id bigint fk, not null角色 tr_id bigint fk, not null10. 用户组表用户组表（TUserGroupRelation）字段名称 字段 类型 备注记录标识 tug_id bigint pk, not null用户 tu_id bigint fk, not null组 tg_id bigint fk, not null11. 组织表组织表（T

12、Organization）字段名称 字段 类型 备注组织 id to_id bigint pk, not null父组 parent_to_id bigint not null组织名称 org_name varchar(64) not null创建时间 gen_time datetime not null组织描述 description varchar(200)12. 操作日志表操作日志表（TLog）字段名称 字段 类型 备注日志 ID log_id bigint pk, not null操作类型 op_type int not null操作内容 content varchar(200) no

13、t null操作人 tu_id bigint fk, not null操作时间 gen_time datetime not null在前两篇文章中，不少朋友对我的设计提出了异议，认为过于复杂，当然在实际的各种系统的权限管理模块中，并不像这里设计得那么复杂，我以前所做的系统中，由只有用户和权限的，有只有用户、权限和角色的，还有一个系统用到了用户、权限、角色、组概念，这个系统是我在思考以前所做系统的权限管理部分中找到的一些共性而想到的一个设计方案，当然还会有不少设计不到位的地方，在设计开发过程中会慢慢改进，这个系统权当学习只用，各位朋友的好的建议我都会考虑到设计中，感谢各位朋友的支持。今天抽时间整

14、了一份概念设计出来，还有一些地方尚未考虑清楚，贴出 1.0 版，希望各位朋友提出宝贵建议。大家也可以点击此处 通用权限管理概要设计说明书自行下载，这是 1.0 版本，有些地方可能还会进行部分修改，有兴趣的朋友请关注我的 blog。1. 引言1.1 编写目的本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。1.2 背景a、 软件系统的名称：通用权限管理系统；b、 任务提出者、开发者：谢星星；c、 在 J2EE 的 web 系统中需要使用权限管理的系统。1.3 术语本系统：通用权限管理系统；SSH：英文全称是 Secure She

15、ll。1.4 预期读者与阅读建议预期读者 阅读重点开发人员 总体设计、接口设计、数据结构设计、界面总体设计、系统出错处理设计设计人员 总体设计、接口设计、数据结构设计、系统安全设计1.5 参考资料通用权限管理系统需求规格说明书通用权限管理系统数据库设计说明书2. 总体设计2.1 设计目标权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。本系统的设计目标是对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。2.

16、2 运行环境操作系统：Windows 系统操作系统和 Linux 系列操作系统。2.3 网络结构通用权限管理系统可采用 Java Swing 实现，可以在桌面应用和 Web 应用系统中进行调用。如果需要要适应所有开发语言，可以将其 API 发布到 WEB Service 上。暂时用 Java Swing 实现。2.4 总体设计思路和处理流程在说明总体设计思路前，我们先说明本系统的相关概念：1. 权限资源系统的所有权限信息。权限具有上下级关系，是一个树状的结构。下面来看一个例子系统管理用户管理查看用户新增用户修改用户删除用户对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例

17、如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。2. 用户应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于 0n 个角色，可属于 0n 个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是 n 对 n 的关系。3. 角色为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。4. 组为了更好地管理

18、用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际情况中，我们知道，组也可以具有自己的角色信息、权限信息。这让我想到我们的 QQ 用户群，一个群可以有多个用户，一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ 群也可以具有自己的角色信息，例如普通群、高级群等。针对如上提出的四种对象，我们可以整理得出它们之间的关系图，如下所示：总体设计思路是将系统分为组权限管理、角色权限管理、用户权限管理、组织管理和操作日志管理五部分。其中组权限管理包括包含用户、所属角色、组权限资源和组总权限资源四部分，某个组的权限信息可用公式表示：组权限 = 所属角

19、色的权限合集 + 组自身的权限。角色权限管理包括包含用户、包含组和角色权限三部分，某个角色的权限的计算公式为：角色权限 = 角色自身权限。用户权限管理包括所属角色、所属组、用户权限、用户总权限资源和组织管理五部分。某个用户总的权限信息存在如下计算公式：用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。组织管理即对用户所属的组织进行管理，组织以树形结构展示，组织管理具有组织的增、删、改、查功能。操作日志管理用于管理本系统的操作日志。注意：因为组和角色都具有上下级关系，所以下级的组或角色的权限只能在自己的直属上级的权限中选择，下级的组或者角色的总的权限都不能大于直属上级的总权限

20、。2.5 模块结构设计本系统的具有的功能模块结构如下图所示：2.6 尚未解决的问题无。3. 接口设计（暂略）3.1 用户接口（暂略）3.2 外部接口（暂略）3.3 内部接口（暂略）4. 界面总体设计本节将阐述用户界面的实现，在此之前对页面元素做如下约定：序号 页面元素 约定1 按钮 未选中时：按钮名称选中时：按钮名称2 单选框 选项3 复选框 选项4 下拉框 选项, 5 文本框 |_|6 TextArea |7 页签 未选中时： 选项名称选中时： 选项名称8 未选中链接 链接文字9 选中链接 链接文字10 说明信息 说明信息4.1 组权限管理4.1.1 包含用户组信息组 1组 11所选择组：组

21、 1 包含用户 所属角色 组权限 总权限组 12组组 2组 21组 22组修改用户名 姓名 手机号 最近登录时间 登录次数阿蜜果 谢星星 13666666666 2007-10-8 66sterning xxx 13555555555 2007-10-8 10 当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该组所包含的用户。4.1.2 所属角色组信息组 1组 11组 12组组 2组 21组 22组所选择组：组 1 包含用户 所属角色 组权限 总权限修改角色 ID 角色名称 角色描述1 访客 -2 初级用户 -当用户选择“修改”按钮时，弹出角色树形结构，操作人可以通过

22、勾选或取消勾选来修改该组所属的角色。4.1.3 组权限组信息组 1组 11组 12组组 2组 21组 22组所选择组：组 1 包含用户 所属角色 组权限 总权限保存 取消4.1.4 总权限组信息组 1组 11组 12组组 2所选择组：组 1 包含用户 所属角色 组权限 总权限组 21组 22组保存 取消通过对已具有的权限取消勾选，或为某权限添加勾选，来修改组的权限信息，点击“保存”按钮保存修改信息。4.1.5 组管理在下图中，选中组 1 的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。组信息组 1组 11组 12组组 2组 2

23、1组 22所选择组：组 1 包含用户 所属角色 组权限 总权限修改用户名 姓名 手机号 最近登录时间 登录次数阿蜜果 谢星星 13666666666 2007-10-8 66sterning xxx 13555555555 2007-10-8 10 组4.2 角色权限管理4.2.1 包含用户角色信息角色 1角色 11角色 12角色角色 2角色 21角色 22角色所选择角色：角色 1 包含用户 包含组 角色权限修改用户名 姓名 手机号 最近登录时间 登录次数阿蜜果 谢星星 13666666666 2007-10-8 66sterning xxx 13555555555 2007-10-8 10

24、当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的用户。4.2.2 包含组角色信息角色 1角色 11角色 12所选择角色：角色 1 包含用户 包含组 角色权限修改角色角色 2角色 21角色 22角色组 ID 组名称 组描述1 xxx1 -2 xxx2 - 当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的组。4.2.3 角色权限角色信息角色1角色 11角色 12角色角色2角色 21角色 22角色所选择角色：角色 1 包含用户 包含组 角色权限保存 取消通过对已具有的权限取消勾选，或为某权限添加勾选，来修改角色的权限信息

25、，点击“保存”按钮保存修改信息。4.2.4 管理角色在下图中，选中组 1 的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。角色信息角色 1角色 11角色 12角色角色 2角色 21角色 22角色所选择角色：角色 1 包含用户 包含组 角色权限修改用户名 姓名 手机号 最近登录时间 登录次数阿蜜果 谢星星 13666666666 2007-10-8 66sterning xxx 13555555555 2007-10-8 10 4.3 用户权限管理4.3.1 所属角色用户权限信息xx 公司广州分公司所选择用户：阿蜜果所属角色 所

26、属组 用户权限 总权限阿蜜果肖 xxyy北京分公司zz1zz2zz3修改角色 ID 角色名称 角色描述1 访客 -2 初级用户 -当用户选择“修改”按钮时，弹出角色树形结构，操作人可以通过勾选或取消勾选来修改该用户所属的角色。4.3.2 所属组用户信息xx 公司广州分公司阿蜜果肖 xxyy北京分公司zz1zz2zz3所选择用户：阿蜜果所属角色 所属组 用户权限 总权限修改组 ID 组名称 组描述1 组 1 -2 组 2 -当用户选择“修改”按钮时，弹出组的树形结构，操作人可以通过勾选或取消勾选来修改该用户所属的组。4.3.3 用户权限用户信息xx 公司广州分公司阿蜜果肖 xxyy北京分公司zz

27、1zz2zz3所选择用户：阿蜜果所属角色 所属组 用户权限 总权限保存 取消通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保存修改信息。4.3.4 总权限用户信息xx 公司广州分公司阿蜜果肖 xxyy北京分公司zz1zz2zz3所选择用户：阿蜜果所属角色 所属组 用户权限 总权限保存 取消通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保存修改信息。4.3.5 用户管理当选择了某用户时，点击右键，弹出菜单列表：修改、删除、取消，点击修改和删除按钮可以实现用户的删除和修改功能。选择某个组织，例如下表中的“广州分公司”，

28、弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加用户按钮可以实现用户的添加功能。用户权限信息xx 公司广州分公司阿蜜果肖 xxyy北京分公司zz1zz2zz3所选择用户：阿蜜果所属角色 所属组 用户权限 总权限修改角色 ID 角色名称 角色描述1 访客 -2 初级用户 -4.3.6 组织管理选择某个组织，例如下表中的“广州分公司”，弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。用户权限信息xx 公司广州分公司阿蜜果肖 xxyy北京分公司zz1所选择用户：阿蜜果所属角色 所属组 用户权

29、限 总权限修改角色 ID 角色名称 角色描述1 访客 -2 初级用户 -zz2zz34.4 操作日志管理4.4.1 查询操作日志操作名称：|_| 操作人：|_|操作时间从 |_| 到 |_| 查询 重置 删除编号 操作名称 操作内容 操作人 操作时间1 xx1 - Amigo 2007-10-82 xx2 - xxyy 2007-10-8输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。4.4.2 删除操作日志操作名称：|_| 操作人：|_|操作时间从 |_| 到 |_| 查询 重置 删除编号 操作名称 操作内容 操作人 操作时间1 xx1 - Amigo 2007-10-

30、82 xx2 - xxyy 2007-10-8输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。而后点击“删除”按钮，可删除符合查询条件的操作日志。5. 数据结构设计数据库设计的模型请参见通用权限管理系统_数据库模型.pdm 。表的说明请参见通用权限管理系统数据库设计说明书。5.1 设计原则5.1.1 命名的规范数据库中表、主键、外键、索引的命名都以统一的规则，采用大小写敏感的形式，各种对象命名长度不要超过 30 个字符，这样便于应用系统适应不同的数据库平台。5.1.2 数据的一致性和完整性为了保证数据库的一致性和完整性，往往通过表间关联的方式来尽可能的降低数据的冗余。表间

31、关联是一种强制性措施，建立后，对父表（Parent Table）和子表(Child Table)的插入、更新、删除操作均要占用系统的开销。如果数据冗余低，数据的完整性容易得到保证，但增加了表间连接查询的操作，为了提高系统的响应时间，合理的数据冗余也是必要的。使用规则（Rule）和约束（Check）来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段，但是，不必要的规则和约束也会占用系统的不必要开销，需要注意的是，约束对数据的有效性验证要比规则快。所有这些，需要在设计阶段应根据系统操作的类型、频度加以均衡考虑。5.2 数据库环境说明数据库：MySql5.0设计库建模工具：PowerD

32、esigner12.05.3 数据库命名规则表名以 T 开头，外键以 FK 开头，索引以 INDEX 开头。5.4 逻辑结构pdm 文件的名称为：通用权限管理系统_数据库模型。5.5 物理存储通过数据库建模工具 PowerDesigner12 可以将 pdm 导出为文本文件，将数据库脚本放入文本文件中保存。5.6 数据备份和恢复数据库需定期备份（每天备份一次），备份文件格式为 backup_yyyyMMdd，数据库被破坏时，利用最新的备份文件进行恢复。6. 系统出错处理设计6.1 出错信息错误分类 子项及其编码 错误名称 错误代码 备注连接超时 100001001连接连接断开 10000100

33、2数据库错误数据库本身错误代码 数据库本身错误代码100002+数据库错误代码连接超时 101001001连接连接断开 101001002TCP 连接错误其它 TCP 连接错误(socket 自身错误代码)101002+ socket 错误代码未配置输入参数 102001配置信息错误未配置输出参数 102002组管理部分自定义错误 103001103999角色管理部分自定义错误104001104999用户管理部分自定义错误105001105999操作日志管理 1060011069996.2 补救措施为了当某些故障发生时，对系统进行及时的补救，提供如下补救措施：a后备技术 定期对数据库信息进行备

34、份（每天一次），当数据库因某种原因被破坏时，以最新的数据库脚本进行恢复；。7. 系统安全设计7.1 数据传输安全性设计SSH 可以通过将联机的封包加密的技术进行资料的传递; 使用 SSH 可以把传输的所有数据进行加密，即使有人截获到数据也无法得到有用的信息。同时数据经过压缩，大大地加快了传输的速度。通过 SSH 的使用，可以确保资料传输比较安全并且传输效率较高。7.2 应用系统安全性设计操作人的操作信息需要提供操作记录。对系统的异常信息需进行记录，已备以后查看。只有授权用户才能登录系统，对于某个操作，需要具有相应权限才能进行操作。7.3 数据存储安全性设计 对于用户的密码等敏感信息采用 MD5 进行加密。