通用权限管理系统开发文档
通用权限管理系统开发文档
部门：地理信息部
作者：王立彪
版本：1.0
时间：2017-01-13
目录
1. 简单模型描述 (1)
1.1. E-R图 (1)
1.2. 表格清单 (1)
1.3. 外键清单 (2)
1.4. 视图清单 (3)
1.5. 序列清单 (3)
2. 完全模型描述 (4)
2.1. E-R图 (4)
2.2. 表格清单 (4)
2.2.1. 表格shiro_user（系统用户表） (4)
2.2.2. 表格shiro_role（系统角色表） (5)
2.2.3. 表格shiro_dept（系统部门表） (5)
2.2.4. 表格shiro_resource（系统资源表） (5)
2.2.5. 表格shiro_permission（系统权限表） (6)
2.2.6. 表格shiro_group（系统组表） (6)
2.2.7. 表格shiro_user_role（系统用户与角色关系表） (6)
2.2.8. 表格shiro_role_resource（系统角色与资源关系表） (6)
2.2.9. 表格shiro_role_permission（系统角色与权限关系表） (6)
2.2.10. 表格shiro_group_user（系统组与用户关系表） (7)
2.2.11. 表格shiro_reource_permission（系统资源与权限关系表） (7)
2.2.12. 表格shiro_group_role（系统组与角色关系表） (7)
2.2.13. 表格shiro_linecese（系统许可证表） (7)
2.2.14. 表格shiro_machine_binding（系统机器绑定表） (7)
2.2.15. 表格shiro_ras_keys（系统非对称加密秘钥表） (8)
2.3. 外键清单 (8)
2.3.1. 外键FK_SHIRO_GR_REFERENCE_SHIRO_DE (8)
2.3.2. 外键FK_SHIRO_GR_REFERENCE_SHIRO_GR (8)
2.3.3. 外键FK_SHIRO_GR_REFERENCE_SHIRO_RO (9)
2.3.4. 外键FK_SHIRO_GU_REFERENCE_SHIRO_GR (9)
2.3.5. 外键FK_SHIRO_GU_REFERENCE_SHIRO_US (10)
2.3.6. 外键FK_SHIRO_MB_REFERENCE_SHIRO_LI (10)
2.3.7. 外键FK_SHIRO_MB_REFERENCE_SHIRO_RK (10)
2.3.8. 外键FK_SHIRO_RE_REFERENCE_SHIRO_PE (11)
2.3.9. 外键FK_SHIRO_RE_REFERENCE_SHIRO_RE (11)
2.3.10. 外键FK_SHIRO_RO_REFERENCE_SHIRO_DE (12)
2.3.11. 外键FK_SHIRO_RP_REFERENCE_SHIRO_PE (12)
2.3.12. 外键FK_SHIRO_RP_REFERENCE_SHIRO_RO (13)
2.3.13. 外键FK_SHIRO_RR_REFERENCE_SHIRO_RE (13)
2.3.14. 外键FK_SHIRO_RR_REFERENCE_SHIRO_RO (13)
2.3.15. 外键FK_SHIRO_UR_REFERENCE_SHIRO_RO (14)
2.3.16. 外键FK_SHIRO_UR_REFERENCE_SHIRO_US (14)
2.3.17. 外键FK_SHIRO_US_REFERENCE_SHIRO_DE (15)
2.4. 视图清单 (15)
2.4.1. 视图view_shiro_user_resource (15)
2.4.2. 视图view_shiro_user_role_permission (17)
2.5. 序列清单 (18)
2.5.1. 序列SHIRO_USER_ID_SEQ (18)
2.5.2. 序列SHIRO_ROLE_ID_SEQ (18)
2.5.3. 序列SHIRO_GROUP_ID_SEQ (18)
2.5.4. 序列SHIRO_RESOURCE_ID_SEQ (18)
2.5.5. 序列SHIRO_PERMISSION_ID_SEQ (18)
2.5.6. 序列SHIRO_LINECESE_ID_SEQ (19)
2.5.7. 序列SHIRO_RSA_KEYS_ID_SEQ (19)
2.5.8. 序列SHIRO_MACHINE_BINDING_ID_SEQ (19)
3. 配置手册 (19)
4. 系统引入工程模板 (19)
1.简单模型描述
1.1.E-R图
图1-1 整体E-R 1.2.表格清单
1.3.外键清单
1.4.视图清单1.5.序列清单
2.完全模型描述
2.1.E-R图
图2-1 整体E-R 2.2.表格清单
2.2.1.表格shiro_user（系统用户表）
2.2.2.表格shiro_role（系统角色表）
2.2.
3.表格shiro_dept（系统部门表）
2.2.4.表格shiro_resource（系统资源表）
2.2.5.表格shiro_permission（系统权限表）
2.2.6.表格shiro_group（系统组表）
2.2.7.表格shiro_user_role（系统用户与角色关系表）
2.2.8.表格shiro_role_resource（系统角色与资源关系表）
2.2.9.表格shiro_role_permission（系统角色与权限关系表）
2.2.10.表格shiro_group_user（系统组与用户关系表）
2.2.11.表格shiro_reource_permission（系统资源与权限关
系表）
2.2.12.表格shiro_group_role（系统组与角色关系表）
2.2.1
3.表格shiro_linecese（系统许可证表）
2.2.14.表格shiro_machine_binding（系统机器绑定表）
2.2.15.表格shiro_ras_keys（系统非对称加密秘钥表）
2.3.外键清单
2.3.1.外键FK_SHIRO_GR_REFERENCE_SHIRO_DE
2.3.1.1.外键FK_SHIRO_GR_REFERENCE_SHIRO_DE的描述
2.3.1.2.外键FK_SHIRO_GR_REFERENCE_SHIRO_DE的连接清单
2.3.2.外键FK_SHIRO_GR_REFERENCE_SHIRO_GR
2.3.2.1.外键FK_SHIRO_GR_REFERENCE_SHIRO_GR的描述
2.3.2.2.外键FK_SHIRO_GR_REFERENCE_SHIRO_GR的连接清单
2.3.3.外键FK_SHIRO_GR_REFERENCE_SHIRO_RO 2.3.3.1.外键FK_SHIRO_GR_REFERENCE_SHIRO_RO的描述
2.3.3.2.外键FK_SHIRO_GR_REFERENCE_SHIRO_RO的连接清单
2.3.4.外键FK_SHIRO_GU_REFERENCE_SHIRO_GR 2.3.4.1.外键FK_SHIRO_GU_REFERENCE_SHIRO_GR的描述
2.3.4.2.外键FK_SHIRO_GU_REFERENCE_SHIRO_GR的连接清单
2.3.5.外键FK_SHIRO_GU_REFERENCE_SHIRO_US 2.3.5.1.外键FK_SHIRO_GU_REFERENCE_SHIRO_US的描述
2.3.5.2.外键FK_SHIRO_GU_REFERENCE_SHIRO_US的连接清单
2.3.6.外键FK_SHIRO_MB_REFERENCE_SHIRO_LI
2.3.6.1.外键FK_SHIRO_MB_REFERENCE_SHIRO_LI的描述
2.3.6.2.外键FK_SHIRO_MB_REFERENCE_SHIRO_LI的连接清单
2.3.7.外键FK_SHIRO_MB_REFERENCE_SHIRO_RK 2.3.7.1.外键FK_SHIRO_MB_REFERENCE_SHIRO_RK的描述
子表格shiro_machine_binding
父表格shiro_rsa_keys
外键列key_id
2.3.7.2.外键FK_SHIRO_MB_REFERENCE_SHIRO_RK的连接清单
2.3.8.外键FK_SHIRO_RE_REFERENCE_SHIRO_PE
2.3.8.1.外键FK_SHIRO_RE_REFERENCE_SHIRO_PE的描述
2.3.8.2.外键FK_SHIRO_RE_REFERENCE_SHIRO_PE的连接清单
2.3.9.外键FK_SHIRO_RE_REFERENCE_SHIRO_RE
2.3.9.1.外键FK_SHIRO_RE_REFERENCE_SHIRO_RE的描述
2.3.9.2.外键FK_SHIRO_RE_REFERENCE_SHIRO_RE的连接清单
2.3.10.外键FK_SHIRO_RO_REFERENCE_SHIRO_DE 2.3.10.1.外键FK_SHIRO_RO_REFERENCE_SHIRO_DE的描述
2.3.10.2.外键FK_SHIRO_RO_REFERENCE_SHIRO_DE的连接清单
2.3.11.外键FK_SHIRO_RP_REFERENCE_SHIRO_PE
2.3.11.1.外键FK_SHIRO_RP_REFERENCE_SHIRO_PE的描述
2.3.11.2.外键FK_SHIRO_RP_REFERENCE_SHIRO_PE的连接清单
2.3.12.外键FK_SHIRO_RP_REFERENCE_SHIRO_RO 2.3.12.1.外键FK_SHIRO_RP_REFERENCE_SHIRO_RO的描述
2.3.12.2.外键FK_SHIRO_RP_REFERENCE_SHIRO_RO的连接清单
2.3.13.外键FK_SHIRO_RR_REFERENCE_SHIRO_RE 2.3.13.1.外键FK_SHIRO_RR_REFERENCE_SHIRO_RE的描述
2.3.13.2.外键FK_SHIRO_RR_REFERENCE_SHIRO_RE的连接清单
2.3.14.外键FK_SHIRO_RR_REFERENCE_SHIRO_RO 2.3.14.1.外键FK_SHIRO_RR_REFERENCE_SHIRO_RO的描述
子表格shiro_role_resource
父表格shiro_role
外键列role_id
2.3.14.2.外键FK_SHIRO_RR_REFERENCE_SHIRO_RO的连接清单
2.3.15.外键FK_SHIRO_UR_REFERENCE_SHIRO_RO 2.3.15.1.外键FK_SHIRO_UR_REFERENCE_SHIRO_RO的描述
2.3.15.2.外键FK_SHIRO_UR_REFERENCE_SHIRO_RO的连接清单
2.3.16.外键FK_SHIRO_UR_REFERENCE_SHIRO_US 2.3.16.1.外键FK_SHIRO_UR_REFERENCE_SHIRO_US的描述
2.3.16.2.外键FK_SHIRO_UR_REFERENCE_SHIRO_US的连接清单
2.3.17.外键FK_SHIRO_US_REFERENCE_SHIRO_DE 2.3.17.1.外键FK_SHIRO_US_REFERENCE_SHIRO_DE的描述
2.3.17.2.外键FK_SHIRO_US_REFERENCE_SHIRO_DE的连接清单
2.4.视图清单
2.4.1.视图view_shiro_user_resource
2.4.1.1.视图view_shiro_user_resource的描述
2.4.1.2.视图view_shiro_user_resource的SQL查询
SELECT
r. ID, r. TYPE, r.resource, r.priority, r.icon, r.parentid, r. NAME,
r.css, r.target, r.is_out, https://www.360docs.net/doc/72210291.html,er_id, NULL :: INTEGER AS group_id
FROM((shiro_resource r
LEFT JOIN shiro_role_resource rr ON ((rr.resource_id = r. ID))
)
LEFT JOIN shiro_user_role ur ON ((ur.role_id = rr.role_id))
)
UNION ALL
SELECT
r. ID, r. TYPE, r.resource, r.priority, r.icon, r.parentid, r. NAME,
r.css, r.target, r.is_out, https://www.360docs.net/doc/72210291.html,er_id, gr.group_id
FROM(((shiro_resource r
LEFT JOIN shiro_role_resource rr ON ((rr.resource_id = r. ID))
)
LEFT JOIN shiro_group_role gr ON ((gr.role_id = rr.role_id))
)
LEFT JOIN shiro_group_user gu ON ((gu.group_id = gr.group_id)) );
;
2.4.1.
3.视图view_shiro_user_resource的表格清单
2.4.1.4.视图view_shiro_user_resource的视图列清单
2.4.2.视图view_shiro_user_role_permission
2.4.2.1.视图view_shiro_user_role_permission的描述
2.4.2.2.视图view_shiro_user_role_permission的SQL查询
SELECT
pr.id, https://www.360docs.net/doc/72210291.html,, pr.type, pr.parent_id,pr.permission, pr.priority,pr.role_id ,https://www.360docs.net/doc/72210291.html,er_id FROM (SELECT p.id, https://www.360docs.net/doc/72210291.html,, p.type, p.parent_id,
p.permission, p.priority,rp.role_id FROM shiro_permission p ,shiro_role_permission rp where p.id=rp.permission_id
UNION all
SELECT p.id, https://www.360docs.net/doc/72210291.html,, p.type, p.parent_id,
p.permission,p.priority,srr.role_id FROM shiro_permission p , shiro_resource_permission srp,shiro_role_resource srr
where srp.permission_id=p."id" and srr.resource_id=srp.resource_id )
pr ,(select gr.role_id,https://www.360docs.net/doc/72210291.html,er_id from shiro_group_role gr,shiro_group_user gu
where gr.group_id=gu.group_id
UNION all
SELECT ur.role_id,https://www.360docs.net/doc/72210291.html,er_id from shiro_user_role ur
) gsur
where pr.role_id=gsur.role_id
2.4.2.
3.视图view_shiro_user_resource的表格清单
系统权限管理设计方案(优选.)
OA系统权限管理设计方案 l 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 l 可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 l 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 l 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 针对OA系统的特点，权限说明： 权限 在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。
角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限，有4种方式(参考飞思办公系统) A. 通过职位 a) 在职位中，职位成员的权限继承当前所在职位的权限，对于下级职位拥有的权限不可继承。 b) 实例中：如前台这个职位，对于考勤查询有权限，则可以通过对前台这个职位设置考勤查询的浏览权，使他们有使用这个对象的权限，然后再设置个，考勤查询权（当然也可以不设置，默认能进此模块的就能查询），则所有前台人员都拥有考勤查询的权利。 B. 通过项目 a) 在项目中，项目成员的权限来自于所在项目的权限，他们同样不能继承下级项目的权限，而对于项目组长，他对项目有全权，对下级项目也一样。 b) 实例中：在项目中，项目成员可以对项目中上传文档，查看本项目的文档,可以通过对项目设置一个对于本项目的浏览权来实现进口，这样每个成员能访问这个项目了，再加上项目文档的上传权和查看文档权即可。
一种通用权限管理方案的设计方案
一种通用权限管理方案的设计方案 分析了权限管理的概念和一些与权限管理容易混淆的概念。提出了一种目前可以应用到绝大多数与权限有关的系统设计中的通用权限管理方案。该方案以角色对用户进行分组，通过用户数据库、角色数据库、权限数据库、用户－权限数据库以及角色-权限数据库来实现权限的分层管理。该设计方案能够由管理员方便的对权限进行设置。通过对角色的权限设置可以达到快速设置权限。通过对用户的权限设置可以达到权限的精确控制。文章最后以某项目为基础对该权限设计方案进行了实现。通过测试，该方案能够很好的对用户权限进行控制，从而提高整个系统的安全性。 标签：权限系统角色数据库 1 权限管理的概念 权限管理是软件系统中最常见的功能之一。所谓权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。权限管理几乎出现在任何系统里面，只要有用户和密码的系统。尤其是在B/S机构的系统中，由于没有专门的客户端软件系统，所以权限管理就显的尤为重要。如果一个B/S系统的权限管理设计的不好，那么一个“非法用户”就可以轻而易举的获取整个系统的所有本能，包括超级管理员的功能。那么这样的系统还有谁敢使用。 很多人，常将“用户身份认证”、“密码加密”、“系统管理”等概念与权限管理概念混淆。用户身份认证，根本就不属于权限管理范畴。用户身份认证，是要解决这样的问题：用户告诉系统“我是谁”，系统就问用户凭什么证明你就是“谁”呢？对于采用用户名、密码验证的系统，那么就是出示密码。当用户名和密码匹配，则证明当前用户是谁；对于采用指纹等系统，则出示指纹；对于硬件Key 等刷卡系统，则需要刷卡。密码加密，是隶属用户身份认证领域，不属于权限管理范畴。 2 权限管理的设计 2.1 权限管理的对象在一般的系统设计中，权限管理的参于对象包括用户对象、角色（或分组）对象、功能模块对象。角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色。功能模块则对不同的系统来说各不相同，一般在系统设计中最终将其以图形界元素的形式表现出来（比如软件界面上的各个功能按钮）。 2.2 权限管理举例下面我们举例说明2.1中提到的用户、角色、功能三个对象在权限管理中具体应用。表1中列出了某文档管理项目中权限管理的一部分设计表。从中我们可以清晰的区别出这三个对象以及它们的各自作用。
银行授权管理操作流程
授权管理操作流程 1目的 本文件规定了XX农村银行（以下简称“本行”）授权管理的流程及控制要点，旨在加强统一授权管理，健全内控和自我约束机制，确保业务经营、人事任免、财务管理以及纠纷处理等方面的授权风险得到有效的管理和控制。 2适用范围 本文件适用于本行在业务经营、人事任免、财务管理以及纠纷处理等方面的授权。 3定义、缩写与分类 3.1定义 1）授权：是指本行对其所属业务职能部门、分支机构和关键业务岗位开展业务权限的具体规定。 2）基本授权：是指授予被授权人和（转）被授权人从事经营范围内的一般业务经营活动及人事和财务管理活动权限的规定。 3）特别授权：是指对法定经营范围内超过基本授权范围的某一特定事项的授权或某项特殊业务、创新业务的授权。经特别授权产生被授权人的特别业务权限只能由被授权人自己行使，但特别授权书上注明允许转授权的情况除外。 4）临时授权：是指（转）被授权人因出差、学习或其他事由需离开工作岗位3个工作日以上，经主管领导批准，将自身权限暂交由他人行使的情形。 5）直接授权：是指本行在其法定经营范围内授予本行行长（或主持全面工作的副行长下同）以及本行直属委员会或领导小组等从事职务行为的具体规定。本行的董事长代表本行履行授权人的职责。 6）转授权：是指经本行同意，被授权人在其被授予的权限范围内，授予他人从事某项职务活动的具体规定，包括：本行行长根据本行章程规定或其他有效授权依据，对本行副行长、本行部门经理及辖内分支机构负责人的转授权。辖内分支机构负责人在转授权权限内对其副行长、会计经理、库管员、客户经理及其他重要岗位人员的再转授权；以及本行部门经理在转授权权限内对本部门内重要岗位人员的再转授权等，副行长、会
通用权限管理系统java权限处理及其实现思路
关键字: 用户权限管理 B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的 事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的 人员编入同一组，然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管 理系统，就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之 间，功能权限是可以重用的，而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。 我们先来分析一下数据库结构：
最经典用户权限管理模块设计
实现业务系统中的用户权限管理--设计篇 B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便 的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致 的人员编入同一组，然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套 管理系统，就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统 之间，功能权限是可以重用的，而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。 我们先来分析一下数据库结构： 首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图：
一种通用的应用系统权限管理的实现方法
收稿日期：2000-10-09 基金项目：国家863/CIMS 并行工程主题资助项目（863-511-930-009） 一种通用的应用系统权限管理的实现方法! 朱建江，王宁生 （南京航空航天大学CIMS 工程研究中心，江苏南京210016） 摘要：从数据库访问权限和应用层各个子系统访问权限两个方面，介绍了一种用于管理信息系统的通用权限管理 方法，并给出了相应的功能模型（DFD ） 和信息模型（ER 图）及部分程序设计代码。关键词：系统权限管理；管理信息系统 中图分类号：TP309.2文献标识码：A 文章编号：1001-3695（2001）07-0062-02 A General Method for the Right Management of Application System ZHU Jian-jiang ，WANG Ning-sheng （CIMS Research Center ，Nanjing Uniuersity of Aeronautics and Astro nautics ，Nanjing Jiangsu 210016，China ） Abstract ：From the two aspect of the accessing right of database and sub-system ，a generaI right management method for management information sys-tem is presented ，and the correspondent function modeI （DFD ），information modeI （ER diagram ）and a part of program code are aIso given .Key words ：System right management ；Management information system !前言一套管理信息系统设计、开发的最后一个步骤就是应用系统的权限管理。所谓权限管理就是应用系统的不同用户，拥有与其角色相配的对特定几个应用子系统（或模块）的不同的操作权限，如对于某模块，系统超级用户拥有“插入、修改、删除、查询”等权限，而对于普通用户仅拥有“查询”权限。应用系统的权限管理从功能模型和信息模型的角度可分为两个层次，即功能层的访问权限管理和数据库访问层的权限管理。目前多数管理软件仅做到应用系统功能层上的权限控制，而没有做到数据库访问层的权限控制。功能层上的权限管理主要有两种，一种是仅控制到应用子系统，即不同的用户可以访问不同的应用子系统的“窗体”，而没有控制到“窗体”上的各个功能菜单。这种做法比较简单，仅在管理信息系统技术发展的初期或非常简单的应用系统中采用，目前多数已经弃之不用。另一种是控制到应用子系统“窗体”上的菜单层，即拥有不同角色的不同用户可以访问不同的应用子系统“窗体”，而且对于窗体上的不同功能菜单拥有不同的权限。这种处理方式是当前系统权限管理技术的主流。然而这种处理方式并没有控制到后台数据库基本表；即什么角色的用户可以对哪些基本表拥有哪几种操作权限。由于仅控制到功能层，并没有给软件用户的系统管理员来说提供一个分配数据库基本表的访问控制界面，系统管理员设置角色权限，给系统用户分配 角色等操作不得不通过手工写SOL 语句来实现， 因此对于系统管理员来说很不方便，尤其是当系统管理员需要分配多个角色、用户时。本文提出一种通用的管理到应用系统功能层和数据库访问层的权限管理方法，对于功能层管理到“窗体”的菜单层，对于数据库访问层管理到基本表和基本表的“增加、删除、修改、查询”等基本操作权限。 " 应用系统权限管理的功能模型设计 ［1］ 功能模型的表达采用数据流程图—Data FIow Diagram （DFD ）。应用系统的权限管理从功能上可分为权限管理基本信息维护、角色管理和用户管理三个处理过程，其相关的数据流、数据存储以及输入、输出关系如图1 所示。 图1应用系统权限管理功能模型（DFD 图） #应用系统权限管理的信息模型设计 信息模型的表达采用“实体—关系图（ER 图）”。在工程 领域，信息模型的设计应满足“三范式”，即非键属性既不函数 依赖于主键，也不传递依赖于主键［2］。在权限管理的信息模 型设计之前首先进行实体的标识。对应用系统功能层和数据库访问层进行权限管理的信息模型应包含以下实体：用户、角色、数据库访问权限、基本表、应用子系统、功能模块访问权限、模块菜单。 系统权限管理信息模型分为两个部分（见图2）：对数据库访问权限的管理和对应用系统功能层的访问权限管理。数据库访问权限的管理包括用户表、角色表、数据库访问权限表、数据库基本表。其中用户表用于存储应用系统的所有用户；角色表用于存储所有角色；数据库基本表用于存储应用系统中的所有数据库基本表；对于一个特定的角色可访问多个应用系统的数据库基本表；一个数据库基本表可被多个角色访问，即角色与数据库基本表之间是“多对多”的关系。在数据库设计中这种“多对多”关系是“非确定的”，必须 予以消除，因此引入“中间实体”、“数据库访问权限表”进行处理。给一个角色分配了权限后，就可将这个角色分配给多个用户，角色表和用户表之间是“一对多”的关系。
信息系统用户帐号和角色权限管理流程
信息系统用户帐号与角色权限管理流程 一、目的 碧桂园的信息系统已经在集团下下各公司推广应用，为了确保公司各应用信息系统安全、有序、稳定运行，我们需要对应用信息系统用户帐号和用户权限申请与审批进行规范化管理,特制定本管理规定。 二、适用范围 适用于公司应用信息系统和信息服务，包括ERP系统、协同办公系统、各类业务应用系统、电子邮箱及互联网服务、数据管理平台等。 三、术语和定义 用户：被授权使用或负责维护应用信息系统的人员。 用户帐号：在应用信息系统中设置与保存、用于授予用户合法登陆和使用应用信息系统等权限的用户信息，包括用户名、密码以及用户真实姓名、单位、联系方式等基本信息内容。 权限：允许用户操作应用信息系统中某功能点或功能点集合的权力范围。 角色：应用信息系统中用于描述用户权限特征的权限类别名称。 四、用户管理 （一）用户分类 1.系统管理员：系统管理员主要负责应用信息系统中的系统参数配置，用户帐号开通与维护管理、设定角 色与权限关系，维护公司组织机构代码和物品编码等基础资料。 2.普通用户：指由系统管理员在应用信息系统中创建并授权的非系统管理员类用户，拥有在被授权范围内 登陆和使用应用信息系统的权限。 （二）用户角色与权限关系 1.应用信息系统中对用户操作权限的控制是通过建立一套角色与权限对应关系，对用户帐号授予某个角色 或多个角色的组合来实现的，一个角色对应一定的权限（即应用信息系统中允许操作某功能点或功能点 集合的权力），一个用户帐号可通过被授予多个角色而获得多种操作权限。 2.由于不同的应用信息系统在具体的功能点设计和搭配使用上各不相同，因此对角色的设置以及同样的角 色在不同应用信息系统中所匹配的具体权限范围可能存在差异，所以每个应用信息系统都需要在遵循《应 用信息系统角色与权限设置规范》基础上，分别制定适用于本系统的《碧桂园应用信息系统角色与权限
权限管理设计
对EMS权限管理模块设计 1.权限设计概述 引言 随着Web服务的复杂度增加以及用户数量和种类的增多，安全问题在理论及工程上都是一个必须考虑的问题，而权限管理是安全问题中一个很重要的方面。因此本文针对权限做了一个分析。 权限可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。 意义 用户管理及权限管理一直是应用系统中不可缺少的一个部分 系统用户很多，系统功能也很多 不同用户对系统功能的需求不同 出于安全等考虑，关键的、重要的系统功能需限制部分用户的使用 出于方便性考虑，系统功能需要根据不同的用户而定制 目标 直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，除了功能的必须，更主要的就是因为它足够直观。
简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将变化的“定制”特点比较强的部分判断为业务逻辑，而将相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。 扩展，采用可继承的方式解决了权限在扩展上的困难。引进Group概念在支持权限以组方式定义的同时有效避免了权限的重复定义。 2.基于角色的权限管理设计（Role-Based Access Control ,RBAC） 权限管理用例图 用例图描述 超级管理员：系统中默认的角色，它是系统中拥有最高权限的角色，它不仅能够管理其他的管理员和用户，而且还可以对系统中每个模块的任一功能进行操作、维护。 普通管理员：它是由超级管理员创建的，并授予权限，它能够管理系统中大部分的功能，它可以查看所有普通管理员、普通用户的信息，它只能对由它自己创建的用户进行编辑、删除操作，和管理拥有权限的模块。 普通用户：它是系统中最低权限的角色，它只能对自己拥有的权限进行操作，一般情况下，它的权限是对信息的浏览和对自己信息的录入，修改。 登陆系统：根据用户拥有的权限不同，用户所能操作的功能多少就不同，所以在登陆系统的时候就要对用户的权限进行判断。 用户管理：这里对本系统的登录用户进行维护。包括，新建、删除、编辑、注销等；系统初始化的时候，用户管理中默认只有一个拥有超级管理员角色的用户，因此在初始化登陆的时候，只能用这个用户登陆，其他的用户由这个用户创建并授予角色。
系统权限管理设计方案.doc
OA系统权限管理设计方案7 OA系统权限管理设计方案 数据库2010-02-2310:09:25阅读13评论0字号：大中小 OA系统权限管理设计方案 l不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 l可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 l权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 l满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 针对OA系统的特点，权限说明： 权限
在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。 角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限，有4种方式(参考飞思办公系统) A.通过职位 a)在职位中，职位成员的权限继承当前所在职位的权限，对
多系统权限设计
多系统权限设计 1.多系统基于角色的权限设计 这种方案是最常见也是比较简单的方案，不过通常有这种设计已经够了，这种方案对于每一个操作不做控制，只是在程序中根据角色对是否具有操作的权限进行控制；这里我们就不做详述.此处采用角色关联模块的方式。 2.多系统基于操作的权限设计 这种模式下每一个操作都在数据库中有记录，用户是否拥有该操作的权限也在数据库中有记录，结构如下：
但是如果直接使用上面的设计，会导致数据库中的_SysUserFuncOperate这张表数据量非常大，所以我们需要进一步设计提高效率，请看方案3 3.多系统基于角色和操作的权限设计
如上图所示，我们通过采用角色分配操作的方式，这样子就可以减少操作权限表（_SysRole FuncOperate）中的记录，并且使设计更灵活一点。 但是这种方案在用户需求的考验之下也可能显得不够灵活够用，例如当用户要求临时给某位普通员工某操作权限时，我们就需要新增加一种新的用户角色，但是这种用户角色是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工权限时删除此角色，我们需要设计一种更合适的结构来满足用户对权限设置的要求。 4.2,3组合的权限设计，其结构如下： 我们可以看到在上图中添加了_SysUserFunc和_SysUserFuncOperate表，使用此表来添加特殊用户的权限。这样在应用程序中我们就需要通过_SysUserFuncOperate和_SysRoleFuncOperat e两张表中的记录判断权限。 当然，有可能用户还会给出这样的需求：对于某一种Operate所操作的对象某一些记录会有权限，而对于其他的记录没有权限，比如说一个内容管理系统，对于某一些频道某个用户有
用户权限设计(三)——通用数据权限管理系统设计
通用数据权限管理系统设计（一） 作者：逸云 前言： 本文提供一种集成功能权限和数据权限的解决方法，以满足多层次组织中权限管理方面的集中控制。本方法是RBAC（基于角色的访问控制方法）的进一步扩展和延伸，即在功能权限的基础上增加数据权限的管理，实现数据权限和功能权限的集中处理。 解释： 功能权限：能做什么的问题，如增加销售订单； 数据权限：能在哪里干什么的问题，如察看北京分公司海淀销售部张三的销售订单； 术语： 资源：系统中的资源，主要是各种业务对象，如销售单、付款单等； 操作类型：对资源可能的访问方法，如增加、删除、修改等； 功能：对资源的操作，是资源与操作类型的二元组，如增加销售单、修改销售单等； 数据类型：业务系统中常用的数据权限类型，如公司、部门、项目、个人等； 数据对象：具体的业务对象，如甲公司、乙部门等等，包括所有涉及到数据权限的对象值；权限：角色可使用的功能，分角色的功能权限和角色的数据权限； 角色：特定权限的集合； 用户：参与系统活动的主体，如人，系统等。 通用数据权限管理系统设计（二） 方法说明： 在实际应用中，数据权限的控制点一般相对固定，如针对公司、部门、个人、客户、供应商等，也就是说数据权限一般针对指定数据类型下的一些数据对象。 本方法中，数据权限的依赖于功能权限，是对功能权限的进一步描述，说明角色在指定的功能点上的数据控制权限。 本方法中采用“没有明确规定即视为有效”的原则，如果没有定义功能的数据权限，则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限，则该用户只具有该类型下指定数据的数据权限。 这段话比较绕口，下面举个例子实际例子。 某公司有北京销售部、上海销售部和广州销售部三个销售部，现在需要定义几种角色：销售总监-- 能察看所有销售部的销售订单； 北京销售经理-- 只能察看北京销售部的所有销售订单； 上海销售经理-- 只能察看上海销售部的所有销售订单； 广州销售经理-- 只能察看广州销售部的所有销售订单；
庞飞-基于web的通用权限管理系统
高级软件工程课程设计 基于web的通用权限管理系统的设计与实现 1 研究现状 权限管理技术的理论研究开始于20世纪60年代末70年代初，所权限管理，就是通过某种途径显示地准许或限制访问能力及范围，从而限制对关键资源的访问，防止非法用户的侵入或者合法用户的不慎操作造成破坏。随着计算机技术和应用的发展，特别是互联网的发展，应用系统对于权限管理的需求开始迅速增加。在随后40年的发展历程中，人们在权限管理技术的研究方面取得了很大的成果，先后出现过多种权限管理访问控制技术。20世纪80年代到90年代初，自主权限管理自主访问控制技术、强制访问控制技术得到了美国国防部制定的橘皮书-可信计算机评估准则的认证。但是，近几年来，人们普遍感到DAC和MAC的权限管理技术无法满足现今日趋复杂的应用系统的安全需求。因此，基于角色的权限管理(RBAC)，便成为人们研究访问控制技术的重点和热点。 2 可行性研究 可行性研究是对项目进行可行性调研和论证，确定项目开发的价值和意义以及是否可以付诸实施。其目的是在对比投入和产出的基础上考虑利用目前的资源、成本等因素能否实现一个系统以及是否会创造价值或带来实际的意义。 可行性分析 可行性分析一般可定义为，可行性分析是在建设的前期对工程项目的一种考察和鉴定，对拟议中的项目进行全面与综合的技术、经济能力的调查，判断它是否可行。 2.1社会可行性分析 通用权限管理系统的开发符合国家法律，能够与社会大系统实现良好的对接。 2.2 技术可行性分析 开发通用权限管理系统具备所需要的条件。开发通用权限管理系统使用的MS Visual Studio 2008系统开发工具。Windows系列操作系统已经是普遍使用的系统，所以在技术上是成熟的。
一个用户权限管理模块的设计思路
一个用户权限管理模块的设计思路： 1. 权限资源（功能资源） 系统的所有权限信息。权限具有上下级关系，是一个树状的结构。如下： 系统管理 单位管理 查看单位 添加单位 修改单位 删除单位 部门管理 查看部门 添加部门 修改单位 删除单位 对于每个权限，又存在两种情况：1可访问；2可授权，部分表中采用拥有类型做判断(0可访问，1即可访问也可授权) 2. 用户 系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n 个组。他的权限集是自身具有的权限+所属的各角色具有的权限+所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。 3. 角色 为了对拥有相似权限的用户进行分类管理，因此定义角色，例如：超级管理员，一般管理员、一般用户等角色。在这里同时也让角色具有上下级关系，形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。 4. 组 为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际应用中，我们知道，组也可以具有自己的角色信息、权限信息。 就好比是javaeye中的圈子，一个圈子可以拥有多个会员，同时一个会员也可以加入多个圈子，对于不同的圈子又有不同的权限信息。(组的解释：例如一个公司中，不同的部门即可划分不同的组来进行权限的分配) 针对以上描述，结构关系如下： 整个模块分为组权限管理、角色权限管理、用户权限管理。 其中组权限管理：组权限 = 所属角色的权限合集 + 组自身的权限。
角色权限管理：角色权限 = 角色自身权限。 用户权限管理：用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。 注意：因为组和角色都具有上下级关系，所以下级的组或角色的权限只能在自己的直属上级的权限中选择，下级的组或者角色的总的权限都不能大于直属上级的总权限。 欢迎大家拍砖，给点建议。
OA系统权限管理设计方案
OA系统权限管理设计方案 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的 功能。 可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组” 进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进 行重新开发。 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源 权限则不能。 针对OA系统的特点，权限说明： 权限 在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。 角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中， 用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。
OA权限管理设计的实现
OA权限管理设计的实现 任何系统都离不开权限的管理,有一个好的权限管理模块,不仅使我们的系统操作自如,管理方便,也为系统添加亮点。 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 针对OA系统的特点，权限说明： 权限 在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。 角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限，有4种方式(参考飞思办公系统) A.通过职位 a)在职位中，职位成员的权限继承当前所在职位的权限，对于下级职位拥有的权限 不可继承。
通用权限管理系统开发文档
通用权限管理系统开发文档 部门：地理信息部 作者：王立彪 版本： 时间：2017-01-13
目录 1. 简单模型描述..............................................错误!未定义书签。 . E-R图..............................................错误!未定义书签。 . 表格清单............................................错误!未定义书签。 . 外键清单............................................错误!未定义书签。 . 视图清单............................................错误!未定义书签。 . 序列清单............................................错误!未定义书签。 2. 完全模型描述..............................................错误!未定义书签。 . E-R图..............................................错误!未定义书签。 . 表格清单............................................错误!未定义书签。 表格shiro_user（系统用户表）.................错误!未定义书签。 表格shiro_role（系统角色表）.................错误!未定义书签。 表格shiro_dept（系统部门表）.................错误!未定义书签。 表格shiro_resource（系统资源表）.............错误!未定义书签。 表格shiro_permission（系统权限表）...........错误!未定义书签。 表格shiro_group（系统组表）..................错误!未定义书签。 表格shiro_user_role（系统用户与角色关系表） ..错误!未定义书签。 表格shiro_role_resource（系统角色与资源关系表）错误!未定义书签。 表格shiro_role_permission（系统角色与权限关系表）错误!未定义书签。 表格shiro_group_user（系统组与用户关系表） ...错误!未定义书签。 表格shiro_reource_permission（系统资源与权限关系表）错误!未定义书签。 表格shiro_group_role（系统组与角色关系表） ...错误!未定义书签。
系统权限设计
系统权限设计 需求陈述 ?不同职责的人员，对于系统操作的权限应该是不同的。可以对“组”进行权限分配。 ?对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的 事情。所以，系统中就提出了对“组”进行操作的概念， 将权限一致的人员编入同一组，然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断 的重用，而不是每开发一套管理系统，就要针对权限管理 部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资 源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能 (以后可以加入权限分配管理的功能，目前暂不考虑) 首先，action表（以下简称为“权限表”），gorupmanager表（以
下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图： 首先，action表（以下简称为“权限表”），gorupmanager 表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图： 这三个表之间的关系是多对多的，一个权限可能同时属于多个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多个管理组，而一个管理组中也可能同时包含多个人员。如下图：
由于这三张表之间存在着多对多的关系，那么它们之间的交互，最好使用另外两张表来完成。而这两张表起着映射的作用，分别是“actiongroup”表（以下简称“权限映射表”）和“mastergroup”表（以下简称“人员映射表”），前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。如下图：
111111111通用权限管理系统详细设计说明书
第一章引言 1.1 编写目的 系统详细设计说明书在概要设计的基础上，对统一权限管理系统的各模块、数据等分别进行了实现层面上的要求和说明。 本文档读者为系统设计人员、软件实现人员等（编码人员、测试人员），为程序的开发提供依据。 1.2 背景 石家庄大学有办公自动化系统、图书管理系统、教务系统、排课系统、宿舍管理系统等等系统。每个系统都有独立的系统管理权限模块，不便于学校系统管理员的统一管理，而且管理成本也比较高。 统一权限管理系统实现以上软件的统一权限管理，实现系统管理、用户管理等功能，是实现单点登录的基础。 1、项目名称是《统一权限管理系统》； 2、本项目的委托单位是石家庄大学，开发单位是安全一班和二班的全体同学，主管部 门信息工程系。 1.3 定义 权限： 角色 数据库建模： 统一权限管理： 三层架构：
1.4 参考文献 用到的参考资料如下表1.1所示： 表1.1 参考资料表
第二章总体设计 2.1 系统功能概述 通过此权限软件来统一管理我们学校所有或大部分系统软件的用户权限，降低整个学校系统的权限分配复杂性、提高可维护性、降低系统管理员的管理成本。为二期的统一用户单点登录工程项目打下了良好的基础。 通过系统概要设计说明书可知，此统一权限管理系统主要实现系统管理、权限管理、用户管理、日志管理等功能。系统功能结构如图2.1所示。 图2.1 系统功能结构图 2.2 系统软件结构 统一权限管理系统的软件结构如图2.2所示。
图2.2 系统软件结构图
第三章数据设计 3.1 静态数据 初始状态下，统一权限管理系统的测试用户，设置初始超级管理员，其登录用户名为admin，密码为123456。 初始测试用户如表3.1所示。 表3.1 初始测试用户表 3.2 动态数据 统一权限管理系统涉及到的基本数据信息有系统信息、系统模块信息、角色信息、划分权限信息、用户信息、分配角色信息、部门信息等。 一、系统信息 系统信息应包含系统编号、系统名称、系统描述信息、显示顺序等，如表3.2所示。 表3.2 系统信息表 二、系统模块信息 系统模块信息应包含模块编号、模块名称、模块描述、模块地址、显示顺序、显示图标等，如表3.3所示。 表3.3 系统模块信息表
RBAC模型的通用权限管理系统的设计
基于RBAC模型的通用权限管理系统的设计(数据模型)的扩展 1 RBAC模型 访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体（用户、进程、服务等）对访问客体（文件、系统等）的访问权限，从而使计算机系统在合法范围内使用；决定用户能做什么，也决定代表一定用户利益的程序能做什么[1]。 企业环境中的访问控制策略一般有三种：自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法（RBAC）。其中，自主式太弱，强制式太强，二者工作量大，不便于管理[1]。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销；2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。 NIST（The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1]。RBAC0模型如图1所示。 a. RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。 b. RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。 c. RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。 d. RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。 2核心对象模型设计