BBCA统一权限管理系统设计方案.docx
《BBCA统一权限管理系统设计方案.docx》由会员分享，可在线阅读，更多相关《BBCA统一权限管理系统设计方案.docx（23页珍藏版）》请在冰豆网上搜索。
BBCA统一权限管理系统设计方案
（此文档为word格式，下载后您可任意编辑修改！
）
统一权限管理系统
设计方案
项目名称：
承建单位：
管理单位：
意见签署页
需求确认栏
用户单位负责人
日期：
用户单位联络人
日期：
承建单位项目负责人
日期：
修订历史记录
日期
版本
说明
作者
V0.1
初稿
刘学文
V0.2
修改
刘学文
第1章引言1
1.1概述1
1.2目标1
1.3术语2
1.4参考资料3
第2章总体设计4
2.1运行环境4
2.2设计思路4
2.3认证服务模式6
第3章功能概述7
3.1系统用例8
3.2处理流程9
3.3应用系统设置11
3.4用户管理模块设置11
3.5权限及菜单设置13
3.6角色管理设置16
3.7应用系统调用方式17
3.7.1身份验证17
3.7.2获取用户权限列表17
3.7.3获取菜单列表17
3.7.4权限管理17
3.8概念模型17
第4章整合SSO19
第1章引言
1.1概述
权限管理是应用系统中不可缺少的一部分，通常的做法是每开发一个系统都要将这部分功能作为一个模块来开发，一般要开发过程包含以下几个步骤：
1.在数据库中建立用户和权限相关的表结构
2.开发用户、角色、权限管理等的功能模块
3.为系统的每个功能加入获取和判断权限的方法
其实在不同的应用系统中，这些功能基本上都是一样的，每个系统都要加入这些大同小异的功能无疑会带来相当多的重复性工作，浪费我们不少宝贵时间。
虽然将这些功能模块化能减轻一些工作，但由于每个系统采用的开发环境不同（如有些系统采用.net技术，有些用J2EE技术），或者虽然采用的开发技术相同，但采用的框架也可能存在差异（如在J2EE技术下有的采用Hibernate，有的采用IBATIS或者直接调用JDBC等），造成将这些权限模块移植到不同的应用系统时还是需要对代码进行相当繁琐的修改。
1.2目标
为了提高功能的可复用性，结合公司以往的成功项目经验，通过统一的系统规划和系统设计，开发一套通用的权限管理系统，将用户管理、权限管理及单点登录功能都集成到该系统中。
该系统主要解决后期新开发的应用系统无需重新开发权限管理模块的工作，不管新开发的应用系统采用的是什么开发环境，都可以通过WebService方法来调用权限管理系统提供的权限认证服务，而且还可以实现用户一次登录、网内通用，避免每进入一个系统都要重复登录的情况。
此外，可以对区域内各信息应用系统的权限分配和权限变更进行有效的统一化管理，实现多层次统一授权，审计各种权限的使用情况，防止信息共享后的权限滥用，规范今后的应用系统的建设。
本文提供一种集成功能权限和数据权限的解决方法，以满足多层次组织中权限管理方面的集中控制。
本方法主要是基于RBAC（角色的访问控制方法）的进一步扩展和延伸，即在功能权限的基础上增加数据权限的管理，实现数据权限和功能权限的集中处理。
1.3术语
功能权限
系统的所有权限信息。
权限具有上下级关系，是一个树状的结构。
如下图：
图表1:
功能权限的树状关系
对于上面的每个权限，又存在两种情况，一个是只可访问，另一种是可授权，例如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。
数据权限
权限所能管理的资源，比如管理哪个部门。
用户
应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。
他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。
它与权限、角色、组之间的关系都是n对n的关系。
角色
为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。
1.4参考资料
序号
文档名称
作者
发布日期
1
2
3
4
第2章总体设计
2.1运行环境
操作系统：
Windows系列操作系统和Linux系列操作系统。
网络结构：
通用权限管理系统采用B/S架构实现，可以在桌面应用和Web应用系统中通过WebService进行调用。
2.2设计思路
权限管理系统的设计结合以往公司的成功项目经验与当前技术快速发展状况，以服务为中心，根据业务需求发现服务、描述服务并设计服务的实现。
主要从以下几方面着手：
1.独立性：
物理上独立：
与各应用系统之间在物理上（部署时）相对独立（出于网络性能考虑，可以部署在相同网络中或部署到多个节点上以达到集群）。
数据独立：
用户和权限数据存储在权限管理系统的数据库中，不同于应用系统的业务数据的存储。
技术独立：
以WebService服务方式提供接口，保证技术实现上与应用系统技术独立（J2EE、.NET程序都可通用）。
图表2.1：
权限管理系统与各应用系统的关系图
2.统一管理：
各应用系统的用户和权限由权限管理系统统一管理，物理上权限管理系统与各应用系统相对独立，但逻辑上集中统一管理。
3.安全性：
基于DES加密机制，使数据在传输与存储上更安全与完整。
4.松耦合：
以服务的方式与应用系统整合，通过WebService请求获取权限列表。
5.通用性：
适合一般应用系统管理授权的要求，整合了其它项目的以往成功经验。
6.基于角色的策略：
将用户与访问权限分离，基于角色的策略更能实现以职责为中心的管理原则。
同时既可满足集中管理，也可满足分散管理的目标权限管理。
集中管理：
由系统管理员对所有岗位的进行全面和具体的职责分工，用户权限按职责角色作出标准细致的划分，以达到集中管理。
分散管理：
系统管理员为下级管理员设置部分权限，并交由下级管理员在其部分权限范围内进行细化各岗位权限，避免权限的漏洞，达到分散、分层管理。
7.以应用系统为基线：
权限管理系统对各应用系统的权限分开管理，以应用系统为基线，在应用系统上设置用户和权限。
8.参数配置：
通过在各应用系统上配置某些参数，使灵活IT技术能快速适应应用系统的实际业务。
如可以通过参数设置是否分配用户组功能，控制某一应用程序的角色是否分配用户组上。
图表3.2：
权限管理系统实现框架
2.3认证服务模式
由终端用户向各应用系统提交访问申请，各应用系统接收到终端用户WEB的请求后，将终端用户的请求重定向到权限管理系统认证，从而建立起用户的权限认证的连接，并由权限管理系统将认证结果返回给应用系统。
用户登录到各应用系统后，根据用户的操作相应的向权限管理系统发出请求权限认证的服务，由权限管理系统的WebService接口作出相应的响应并还回权限认证结果给应用系统。
如下图：
图表2.3：
认证服务模式
第3章功能概述
权限管理系统主要包含三层，分别为外部访问模块层、内部控制模块层、数据储存层。
外部访问模块层主要为外部应用程序提供WebService接口，提供应用程序的访问与用户认证。
内部控制模块层主要是处理权限管理系统的内部业务逻辑，并通过数据储存层持久化数据。
图表2.3：
权限管理功能结构
3.1系统用例
根据业务的分析可以得出以下用例图：
图表3.1:
权限管理系统用例图
3.2处理流程
权限管理系统内部处理流程如下：
图表3.2:
系统设置用户权限流程图
应用程序处理请求流程：
图表3.3:
用户请求流程图
3.3应用系统设置
权限管理系统可以管理多个应用系统的用户权限，如果某个应用系统需要通过本权限管理系统来管理用户和权限的话，那么首先要通过权限管理系统的[应用系统设置]功能添加一个应用系统。
图表3.4:
添加应用系统
3.4用户管理模块设置
本系统的用户是从属于应用系统的，用户的信息主要是为登录应用系统而服务。
故本系统的用户信息只存储和用户权限相关的信息，和用户相关的人员信息（如：
性别、出生日期、联系电话、地址、电话等）还是保存在各个应用系统中，通过唯一标识来关联。
字段名
描述
用户ID
无业务意义主键
用户名
登录某应用系统的用户名
密码
登录应用系统的密码
姓名
该用户的姓名
唯一标识
如身份证号、学生证号等，根据此标识关联应用系统中的人员信息。
部门
用户所属的部门，可用于设置数据权限
Email
可能会增加通过邮件地址找回密码等功能。
所属应用系统
上一步分配的应用系统
用户信息可以单个录入或批量导入，批量导入主要是应用于应用系统初始化数据时，将人员的信息批量导入到权限管理系统中作为用户信息。
导入的界面如下：
图表3.5:
从应用系统批量导入用户信息
备注：
导入用户信息的sql语句必须包括：
userName，password，fullName，department,idCardNo，systemId六个字段。
导入完成后可以通过用户查询界面看到这些用户，并可以通过编辑用户的信息来设置用户名、密码等信息，以及给用户分配角色，当一个用户属于多个角色时，其拥有的权限是这些角色所拥有的权限的并集。
图表3.6：
编辑用户信息
以后应用系统中再增加人员时，可以通过手工方式进入权限管理系统中为该用户分配权限，也可以通过增加用户的ＷebService自动为该用户在权限管理系统中分配用户。
对于普通用户修改密码，可以在应用系统中请求WebService提供接口解决。
自定义用户属性：
用户属性一般用于定义数据权限，当系统固定的用户属性不能满足要求时，可以自己定义用户属性。
3.5组织机构管理
3.6权限及菜单设置
◆菜单设置：
主要作用是为了控制各应用系统中的菜单权限。
图表3.7：
菜单设置界面
菜单为树状结构，当上级菜单ID为“-1”时表示该菜单是一级菜单，没有上级。
每个菜单项都对应一个功能权限，当用户无权访问该功能权限时，该菜单项不可见。
字段名
字段类型
可为空
默认值
描述
MENUID
VARCHAR2（20）
N
菜单ID
PARENTID
VARCHAR2（20）
N
上级菜单ID
MENUNAME
VARCHAR2（20）
N
菜单名称
DESCRIPTION
VARCHAR2（50）
Y
描述
IDORDER
NUMBER（12）
N
排序值
ICON
VARCHAR2（50）
Y
图标
URL
VARCHAR2（255）
Y
链接文件
PATH
VARCHAR2（255）
N
路径
PURVIEWID
VARCHAR2（20）
N
权限ID
OPENTYPE
CHAR
（1）
Y
0
0-正常;1-全屏;2-新窗口
◆功能权限设置：
主要作用为了控制用户访问应用系统的功能范围
图表3.8：
权限设置界面
权限也是树状结构，当上级权限ID为“-1”时表示该权限没有上级权限。
字段名
字段类型
可为空
默认值
描述
PURVIEWID
VARCHAR2（20）
N
权限ID
PPURVIEWID
VARCHAR2（20）
Y
上级权限编码
PURVIEWNAME
VARCHAR2（50）
N
权限名称
PATH
VARCHAR2（255）
N
路径
◆数据权限设置
数据权限主要包数据表内容过滤与数据表的列过滤。
1.内容过滤可以通过设计过滤条件实现，如下：
图表3.9：
数据过滤设置界面
2.行过滤主要是控制显示的结果列，属于业务范围可由应用系统自行实现。
3.7角色管理设置
角色管理主要是管理授权，允许指定应用程序中的用户可以访问的资源。
角色管理允许向角色分配系统权限（如人员管理员的增加操作、修改操作等），从而将控制用户的访问权限。
在编辑角色的操作中，用户可以为该角色选择相应的权限，如下图：
图表3.10：
角色设置界面
3.8应用系统调用方式
3.8.1身份验证
用户登录一个应用系统时，当他提交登录表单后，应用系统调用本权限管理系统的身份验证服务来判断用户名和密码是否匹配。
参数列表：
系统ID（所属应用系统），用户名，密码
返回结果：
访问系统标志（0不可访问；1可访问；）（，成功登录的TOKEN）
3.8.2获取用户权限列表
如果用户登录成功，应用系统再调用本权限管理系统提供的获取权限列表的服务得到该登录用户的权限列表保存到Session中，以便操作各个功能时，可以判断该用户是否有相应的操作权限。
参数列表：
系统ID（所属应用系统），菜单ID（模块ID），用户名（，TOKEN）
返回结果：
返回用户权限列表LIST
3.8.3获取菜单列表
进入用户主界面时，应用系统调用本权限管理系统的获取菜单列表的服务来获取该用户有权查看的权限列表，然后根据这个列表生成界面菜单。
参数列表：
系统ID（所属应用系统），用户名（，TOKEN）
返回结果：
返回系统菜单列表LIST
3.8.4权限管理
应用系统集权了本权限管理系统后，相应的权限管理和修改用户密码的操作都是直接通过超链接的方式跳转到权限管理系统来进行，因为用户登录应用系统时，也会登录到单点登录系统，所以访问权限管理系统的这些功能时无需再次登录。
3.9概念模型
一个用户对应多个系统
一个系统可以设置多个菜单功能
一个菜单功能可以设置一个权限
权限之间有上下关系
一个系统可以设置多个角色
一个用户可以设置多个角色
一个角色可以设置多个权限
图表3.11：
概念模型图
第4章整合SSO
图表4.1：
整合SSO图
本权限系统默认整合了我们已有的KSSO单点登录产品，KSSO已经在多个项目中得到了应用，具有简单实效，快捷安全的特点。
KSSO系统中有一个Passport服务器，若干个成员系统。
成员系统的登录和检查登录状态的操作都要通过请求Passport的相应接口完成。
PassportServer负责完成对用户的认证工作，处理用户名/密码等凭证（Ticket），提供一种灵活但同一的接口/实现分离的方式，凭证认证方式跟协议是分离的，认证的实现细节可以由用户自己定制和扩展。
PassportServer的应用主要有四个包组成：
用户管理、Key管理、身份验证、URL转发和Cookie管理。
成员系统实际上是单点登录的客户端，当有对本地Web应用的受保护资源的访问请求，并且需要对请求方进行身份认证，Web应用不再接受任何的用户名密码等类似的验证，而是重定向到PassportServer进行认证。
目前，KSSO支持包括Java、.Net、Php、Ruby、VBScript等客户端，几乎可以这样说。
另外本系统也可以整合IBM的ITIM和ITAM二大产品单点登录系统（SSO）主要功能，提供用户集中管理、身份统一认证，并实现用户的一次性认证登录，可直接访问各WEB应用系统的系统资源。
用户通过单点登录系统（SSO）请求访问WEB应用系统资源，由单点登录系统（SSO）进行用户身份统一认证。
验证合法身份后，单点登录系统（SSO）根据用户的请求直接转向到各WEB应用系统，再由各应用系统根据用户相应的操作向权限管理系统提交权限认证的服务申请。
权限管理系统依申请由WebService接口作出相应的响应并还回权限认证结果给各应用系统，实现对用户权限的控制。
第5章需要强调的观念
因为要考虑通用性，权限系统能够实现的功能比较有限，在个别方面甚至会带来额外的一些工作量，你开发的应用系统要不要集成权限管理系统呢？
可以通过以下前三条来衡量，如果权限管理系统能带给你的利益能多于你为集成它而花费的成本，那么可以考虑使用。
5.1权限系统能做什么？
1）通过集成权限系统用户可以不用再去开发一个权限管理的模块，通常这些模块都包括用户管理、权限管理、角色管理、用户组管理、菜单管理等。
这些工作可以在应用系统中通过单点登录来访问。
2）通过集成权限管理系统可以省掉开发登录验证和获取用户权限列表、获取用户菜单列表的工作，应用系统只要调用权限管理系统的相应服务（登录方法）就能获取到。
5.2权限管理系统不能做什么
1）权限系统不能帮应用系统维护人员的信息。
2）权限系统不能帮应用系统维护组织机构信息。
3）权限管理系统不能帮应用系统控制页面或功能按钮的访问。
在权限管理系统中权限管理就是：
预定义好树状结构的一些名称和代码—即权限，然后将这些代码分配给用户，至于用户拿到这些代码后能做什么权限管理系统是不关心的，需要应用系统去控制。
5.3集成权限管理系统会带来哪些额外的工作？
另外集成权限管理系统可能会带来的额外工作量有如下几点：
1）要集成权限管理系统必须要有WebService调用组件和XML解析组件。
2）要集成权限管理系统必须要将与用户相关的人员信息导入到权限系统，以后在应用系统中人员信息发生变化可能会影响权限信息时还必须通过调用权限系统的服务将相应的变化信息同步到权限系统。
5.4权限并不等于菜单
权限：
权限是指预定义好树状结构的一些名称和代码，应用系统可以通过这些名称和代码去控制用户对某些页面和功能按钮的访问。
菜单：
菜单其实就是一些快捷方式。
在B/S系统中，你不通过点击快捷方式也一样可以通过其它方式（如在地址栏直接输入URL）来访问某个页面。
但是当如果这些页面都会根据用户身份（即他所拥有的权限）来决定是否允许用户访问时，即使你能知道所有的快捷访问（菜单），你也不一定能访问这些快捷方式指向的页面。
菜单和权限的关系：
我们可以通过为每个菜单项分配一个权限来控制用户登录时，他有什么样的权限就能看到什么样的菜单，他没有权限的菜单则不会显示出来，以免造成混淆，具体如何显示这需要在应用系统中实现。
升级会员 