基于webservices的统一权限系统说明书.doc

基于 Web Services 的统一权限系统目录 第 1 页 共 82 页 目录目录 摘要摘要4 ABSTRACT5 第第 1 章章引言引言6 1.1.权限系统在信息系统中的地位6 1.2.研究背景6 1.3.本论文的工作内容7 1.4.本文的章节安排7 第第 2 章章权限系统现状分析权限系统现状分析8 2.1.传统的权限系统架构8 2.2.传统的权限系统的不足之处8 2.2.1.不易维护9 2.2.2.不能支持不同平台和架构的软件9 2.2.3.不方便共享数据9 2.2.4.系统安全性降低9 2.2.5.操作不直观，不方便9 第第 3 章章新的解决方案分析新的解决方案分析10 3.1.新的解决方案10 3.2.可行性分析11 3.3.与类似系统的比较12 3.3.1.与单点登陆系统（SSO）的比较12 3.3.2.与 Portal 门户系统的比较13 3.3.3.比较的结论14 第第 4 章章统一权限系统的设计统一权限系统的设计15 4.1.设计目标15 4.2.统一权限系统与业务系统的关系15 4.3.权限控制的方式15 4.3.1.注册业务系统15 4.3.2.权限控制的基本方式16 4.3.3.系统基本权限16 4.3.4.改进后权限控制方式17 4.4.基于角色的权限管理17 4.4.1.用户17 4.4.2.角色18 4.4.3.权限配置20 4.4.4.权限一览20 4.4.5.用户鉴别20 基于 Web Services 的统一权限系统目录 第 2 页 共 82 页 4.4.6.访问控制机构21 4.5.领域模型21 4.6.系统权限认证流程22 4.7.权限的抽象模型24 第第 5 章章核心模块的设计核心模块的设计26 5.1.用户管理模块26 5.2.业务系统功能操作登记模块26 5.3.权限管理模块27 5.3.1.角色管理27 5.3.2.角色与用户关联功能28 5.3.3.角色与操作关联28 5.4.计算权限数据模块29 5.4.1.公用的权限数据29 5.4.2.用户自身的权限数据29 5.5.日志模块30 5.6.系统的扩展功能30 5.6.1.对角色增加类别字段30 5.6.2.更加灵活的设置操作的作用范围31 5.6.3.动态属性管理31 5.7.业务系统通过客户端访问统一权限系统32 5.7.1.数据传输格式32 5.7.2.数据传输方式32 5.7.3.将业务系统需要用到的功能封装成接口32 第第 6 章章系统的实现系统的实现33 6.1.技术架构33 6.1.1.Web Services 技术简介.33 6.1.2.Web Services 关键技术.34 6.2.采用 Apache Axis 序列化和反序列化器35 6.3.系统开发环境36 6.3.1.硬件环境36 6.3.2.软件环境36 6.4.选择 J2EE 平台37 6.4.1.Web 组件38 6.4.2.业务逻辑组件39 6.4.3.J2EE 容器.39 6.5.选择 EJB.40 6.5.1.Web + EJB 能组成真正的多层结构40 6.5.2.EJB 提供性能优化支持41 6.5.3.CMP 独特的优点41 6.5.4.EJB 提供了事务机制42 6.6.发布成 Web Services 服务42 6.6.1.发布42 6.6.2.XML 配置文件43 基于 Web Services 的统一权限系统目录 第 3 页 共 82 页 6.6.3.编写访问 Web Services 服务通用程序43 6.6.4.编写业务系统使用的客户端程序44 6.6.5.解决了权限系统的改动影响业务系统的问题45 6.7.与业务系统的部署45 第第 7 章章系统的优化系统的优化46 7.1.性能问题46 7.1.1.采用异步模式计算权限数据提高性能46 7.1.2.采用缓存技术提高性能46 7.1.3.采用设计模式提高 EJB 性能.48 7.1.4.采用其他方式提高性能50 7.2.用户令牌问题50 第第 8 章章总结总结51 参考文献参考文献52 致谢致谢54 基于 Web Services 的统一权限系统摘要 第 4 页 共 82 页 摘要摘要 目前比较流行的权限系统是用于相同技术开发、部署环境相同的系统中， 这种系统大多是采用代码复用和数据库结构复用的方式将权限管理模块集成到 业务系统中。这样的架构在开发和维护中都存在很多问题，尤其是对于不同架 构、不同部署环境的软件，必须开发并维护不同的权限系统，用户和权限的管 理和维护既不直观也不方便。 本文提出了基于 Web Services 技术的统一权限系统架构，采用这样的架构， 可以使权限系统从业务系统中独立出来，多个不同的业务系统能够共享一个权 限系统，业务系统不必再关心权限方面的细节，从而可以将精力全部放到具体 业务功能的开发上。而且 Web Services 的最大的优点就是整合异构系统间的数 据。这就打破了 B/S，C/S 架构的限制，也不存在 Windows 和 Unix 的平台的选 择了。而且用户和权限都是通过“统一权限系统”统一管理，所以可以非常方 便的控制数据的唯一性。 统一权限系统设计上采用基于角色的权限管理方式，通过 Web Services 实 现权限控制，并封装了统一权限系统客户端 jar 包供业务系统使用。同时采用 缓存结构、EJB 设计模式及异步计算权限数据的方式提高了系统性能。 本文采用 J2EE 平台，JSP、Servlet、EJB、XML、Web Services 技术， Oracle 数据库，Weblogic 应用服务器实现了该系统，开发过程中采用适当的设 计模式提高了系统的完善性、健壮性、可扩展性。 关键词关键词 权限系统;统一;J2EE;Web 服务;UML 基于 Web Services 的统一权限系统ABSTRACT 第 5 页 共 82 页 ABSTRACT The popular authority system is implemented by the same technology and deployment environment as the business system. In this way, the authority system is integrated into the business system by code and data structure reuse. There are many problems in this architecture. For example, Two authority systems must be built to manage the authority on the window and unix platform, then the management is not so easy and convenient. This paper presents the unified authority system architecture based on web services technology. According to the architecture, the business systems share the single same authority system, then the developers of the business system neednt care about the implement detail of the authority, so they can put all their heart to develop the business function. The advantage of web services is to integrate data among difference systems. By this method, the unified authority system can be used by any platform. Distributing and administering authority of the unified authority system is based on role, and at the same time to improve the performance of the system with the cache structure, the design pattern of EJB, and the optimizing method of calculating authority data. The unified authority system is implemented by J2EE, EJB, XML, Web Services, Oracle, Weblogic etc. Keywords Authority System; Unified; J2EE; Web Services; UML 基于 Web Services 的统一权限系统第 1 章 引言 第 6 页 共 82 页 第第 1 章章引言引言 1.1.1.1.权限系统在信息系统中的地位权限系统在信息系统中的地位 对于信息管理系统，不管大型的企业级系统，还是小型的单机系统，抽象 出来，都是由两个主要的引擎组成：一是管理系统权限的身份认证引擎，解决 “用户在什么时间、什么范围能做什么事情” ，另一个是管理任务流程的工作流 引擎，解决“按什么样的步骤去做事情” 。本文主要讨论前者，采用 Web Services 技术，使权限系统从传统的业务系统中独立出来，形成“统一权限系 统” ，使多个不同的业务系统共享同一个权限系统，业务系统不必再关心权限方 面的细节，从而可以将精力全部放到具体业务功能的开发上。 在任何的信息系统中，权限管理都处于核心的地位。权限管理既要保障系 统的安全，又要方便管理和使用。如果将信息系统比作仓库，各个业务系统比 作仓库中不同的房间，业务系统提供的功能比作房间中存放的货物，那么权限 管理就是仓库大门和每个房间门上的锁，如果没有锁，仓库就任人进出自由， 没有安全可言；而如果每个房间都用了不同的锁，则钥匙太多，开锁太麻烦， 让人来去不便。如何为信息系统设计一把称心如意的“锁” ，既要保障仓库的安 全，又要让人进出方便自如？这就是本文要解决的问题。采用 Web Services 技术，打造“统一权限系统”这把锁，当所有的业务系统都使用同样 的新锁（或改装原来的锁变为新的锁） ，那么业务系统就不必再关心“锁”的问 题，从而可以将全部的精力放到具体业务功能的开发上。 1.2.1.2.研究背景研究背景 上世纪九十年代，几乎所有券商的信息系统均采用外购的方式构建，券商 的 IT 人员只负责维护，经实践证明，只有像证券交易系统这类不需要经常变动 的软件运行效果不错外，其他日常信息系统（如 OA 系统，报表系统等）运行的 效果都非常的差。其主要原因是日常信息系统经常要修改功能和增加新的模块， 这就要和软件供应商进行沟通，经常会因为时间和经费的原因放弃了一些很好 的想法，系统也因此更新慢或长时间不更新，不能满足日益增长的需求变化。 作为一家 2003 年新成立的综合类券商，第一证券有限公司在筹建的时候，高层 领导就认识到了自主研发的重要性，投入了大量的资金和人力，组建自己的开 发团队，负责全公司综合信息系统的开发和维护，并提出了做到行业内领先的 目标。 公司虽然处于起步阶段，信息系统一无所有，但领导对于信息系统建设的 基于 Web Services 的统一权限系统第 1 章 引言 第 7 页 共 82 页 起点要求并不低，要力争达到简单方便的维护性，较强的扩展性，较好的健壮 性。而且公司今后的发展会越来越依靠信息系统，业务系统也会越来越多，比 如 OA 系统、CRM 系统、CRU 系统、稽核系统等等，这些系统中，对权限控制方 面的要求都非常高，特别是跟管理和财务挂钩的 CRU 和 CRM 系统，所以要花了 大量精力在权限系统的设计和开发上，于是也就有了本文提出的统一权限系统。 1.3.1.3.本论文的工作内容本论文的工作内容 本论文提出了基于 Web Services 技术的统一权限系统架构，采用这样架构， 可以将权限系统从业务系统中独立出来，多个不同的业务系统能够共享一个权 限系统，业务系统不必再关心权限方面的细节，从而可以将精力全部放到具体 业务功能的开发上。而且将权限系统封装成服务，为其他系统提供支持，成为 SOA 架构的一个实用案例。 目前比较流行的权限系统架构在开发、维护、使用中或多或少都存在一些 问题，尤其是对于不同架构、不同部署环境的软件。本文采用 Web Services 技 术解决了这些问题，主要讨论了如何实现这样的架构，并分析了在设计和实现 中遇到的问题，并给出了相应的解决方案、 技术实现上，采用 J2EE 平台，JSP、Servlet、EJB、XML、Web Services 技术，Oracle 数据库，Weblogic 应用服务器来实现该系统，开发过程中采用适 当的设计模式来提高系统的完善性、健壮性、可扩展性。 1.4.1.4.本文的章节安排本文的章节安排 本文共分为七个章节，详细地探讨了统一权限系统的设计和实现过程。 本章从剖析现有的证券信息系统弊端入手，分析了现有系统对信息管理与 渠道整合的不足，简单介绍了本文的现实意义。 第二章剖析了权限系统的现状，讨论了其存在的不足之处。 第三章针对传统权限系统存在的弊端，提出了统一权限系统架构，并讨论 了新架构的可行性。 第四章讨论了统一权限系统的基本设计，其中详细介绍了基于角色的权限 分配和管理策略、权限的抽象模型等。 第五章讨论了统一权限系统中核心模块的设计，以及重点技术难题的解决。 第六章介绍了统一权限系统的技术架构、实现的技术平台、技术关键点， 基于 Web Services 的统一权限系统第 1 章 引言 第 8 页 共 82 页 并对系统的性能的优化提出了几个改进方法。 最后一章总结了统一权限系统的所带来的好处，以及还存在的不足，并对 未来的工作进行了展望。 基于 Web Services 的统一权限系统第 2 章 权限系统现状分析 第 9 页 共 82 页 第第 2 章章权限系统现状分析权限系统现状分析 2.1.2.1.传统的权限系统架构传统的权限系统架构 目前的权限系统，大多数是采用代码复用和数据库结构复用的方式集成到 具体的业务系统中1，例如某公司的信息系统有若干个子系统（OA 系统、CRM 系统、稽核系统、财务系统等等） ，而这些系统可能部署在不同的服务器上，也 有可能是完全不同的软件架构（有些是基于 B/S 结构的 Web 项目，有些又是基 于 C/S 结构的应用程序等等） ，更可能部署在不同的平台上（有些部署在 Windows 平台上，有些又部署在 Unix 平台上） ，每个系统中均有一个代码相同 的权限管理模块，来管理自己系统中用户的权限，这些权限的数据可能是共享 的（数据保存在各系统均能访问的同一个数据库中） ，或者根本就是独享的（数 据保存在自己的数据库中） 。 传统的权限系统如图 2.1 所示： 图 2.1：传统的权限系统部署 2.2.2.2.传统的权限系统的不足之处传统的权限系统的不足之处 对于软件产品开发公司，也会碰到同样的问题，公司的多个不同产品，不 管是开发过程，还是发布后，都得将权限系统集成到产品系统中。 这样做有如下的不足之处： OA系统 OA应用服务器 OA业务数据 OA权限数据 权限模块 公共权限数据库 其他业务系统 其他业务系统 应用服务器 业务数据 权限数据 权限模块 CRM系统 CRM应用服务器 CRM业务数据 CRM权限数据 权限模块 公共权限数据 管理模块 基于 Web Services 的统一权限系统第 2 章 权限系统现状分析 第 10 页 共 82 页 2.2.1. 不易维护不易维护 这是采用代码复用和数据库结构复用方式的普遍缺点，一旦权限系统做了 修改或升级，维护成本会很高。因为权限系统是采用代码复用和数据库结构复 用的方式实现的，所以一旦权限系统做了修改或者升级，则需要更新所有系统 中的权限管理代码及数据库结构，而且要保证所有系统中已有的权限数据能平 滑的过渡。这样的维护工作量是难以想象的，而且需要人工干预，也无形中增 加了系统复杂度，对于开发人员和维护人员来说都是一件“痛苦”的事情。 2.2.2. 不能支持不同平台和架构的软件不能支持不同平台和架构的软件 对于不同架构、不同部署环境的软件，必须开发不同的权限系统。例如 B/S 架构和 C/S 架构的软件的就必须开发不同的权限管理系统，部署在 Windows 下和 Unix 下的软件有时候也要开发不同的权限管理系统。 2.2.3. 不方便共享数据不方便共享数据 权限系统中经常要共享一些数据：比如用户信息、部门结构，职位结构等 等数据，每个业务系统都需要用到这些数据。而权限的数据共享是基于数据库 级的，这就需开发额外的程序来管理系统中共享数据，业务系统只能使用这些 数据，而不能更改这些数据。这也造成开发成本和维护成本的双重增加。 2.2.4. 系统安全性降低系统安全性降低 由于数据是基于数据库级别的共享，每个子系统都能直接访问数据库，所 以在安全性比较差。 2.2.5.操作不直观，不方便操作不直观，不方便 权限的管理和维护不方便，需要进入到各个业务系统的权限管理模块才能 管理对应的权限，操作复杂，且不直观。 基于 Web Services 的统一权限系统第 3 章 新的解决方案分析 第 11 页 共 82 页 第第 3 章章新的解决方案分析新的解决方案分析 3.1.3.1.新的解决方案新的解决方案 由于传统的权限系统存在以上的不足，所以有理由要寻找更好的权限系统 解决方案。 仔细分析传统权限系统的不足，不难发现问题主要集中在三点： 1、要改变目前基于代码和数据库结构复用的模式，使权限系统的修改和升 级尽量不要影响业务系统。 2、要寻找更好的方式共享系统中公用的权限数据。 3、要能方便的管理整个系统中的用户权限。 再仔细考虑一下权限系统的主要作用： 1、管理业务系统的权限，登记功能，并给用户分配权限。 2、让业务系统知道用户在哪些范围内可以执行哪些操作，以正确显示用户 能看到的界面。 3、用户能根据自己的权限情况，来管理自己的权限（例如：如果用户拥有 授权权限，则他可以将自己的权限授权给其允许授权的对象） 。 对比一下前面提到的权限系统的不足和主要作用，本文发现，可以将权限 系统的大部分功能从业务系统中抽象出来，形成一个独立的系统， “统一权限系 统” ，业务系统只保留权限查询和读取系统共用数据的功能。 “统一权限系统” 通过两个方式向业务系统提供服务： 1、通过 Web Services 向子系统提供权限查询服务 2、通过 Web 页面服务向子系统提供权限管理服务（功能登记、权限授予、 权限变更等等） 。 统一权限系统部署示意图如图 3.1 所示： 基于 Web Services 的统一权限系统第 3 章 新的解决方案分析 第 12 页 共 82 页 图 3.1：传统的权限系统部署 3.2.3.2.可行性分析可行性分析 异构系统之间的通讯也正是 Web Services 大展身手的领域，经过改进的架 构可以这样的设计可以很好的弥补传统架构的不足： 1、因为权限是集中式管理，业务系统中只需使用 Web Services 客户端接 口（class jar 包）来查询权限数据及获得系统共享的数据。客户端只是个接 口，而具体的实现代码是放在“统一权限系统”中的。这些 Web Services 客户 端接口以包的形式引入到业务系统中使用。权限系统的修改和升级不会影响到 业务系统，因为业务系统使用的只是 Web Services 客户端接口而已，这些接口 一般是不会改变的，只要保持客户端接口名字不变，统一权限系统的修改和升 级就不会影响到业务系统。即使接口名字改变了，也可通过方法重构的方式修 改接口包，业务系统中只需要重新引入新的包即可完成更新。 2、权限系统中的公用数据是通过 Web Services 服务进行共享，解决了基 于数据库级共享数据的不足。对客户端调用来说，不仅数据库的结构是透明的， 而且可以通过调用接口来实现调用权限的限制。 3、用户和权限都是通过“统一权限系统”的 Web 页面统一管理，并可实现 用户的单点登陆。 OA系统 OA应用服务器 业务数据 权限系统 Web Services 客户端接口 统一权限系统 统一权限系统 应用服务器 权限数据 Web Services Provider WS接口 其他业务系统 其他业务系统 应用服务器 业务数据 权限系统 Web Services 客户端接口 CRM系统 CRM应用服务器 业务数据 权限系统 Web Services 客户端接口 SOAP SOAP SOAP 基于 Web Services 的统一权限系统第 3 章 新的解决方案分析 第 13 页 共 82 页 4、Web Services 的最大的优点就是整合异构系统间的数据。只要是采用 Web Services 标准的软件，都可以来访问 Web Services 服务，这就打破了 B/S，C/S 的软件架构限制，也不存在 Windows 和 Unix 的平台限制了。 基于以上的分析，用 Web Services 来实现权限的统一管理是完全可行，而 且是非常有必要的2。 3.3.3.3.与类似系统的比较与类似系统的比较 可能有人觉得本文提出的系统和现在比较流行的一些系统雷同或类似，其 实并非如此。下面将做出讨论。 3.3.1. 与单点登陆系统（与单点登陆系统（SSO）的比较）的比较 在信息系统的建设过程中，多个应用系统一般是在不同的时期开发完成的。 各应用系统由于功能侧重、设计方法和开发技术有所不同，也就形成了各自独 立的用户库和用户认证体系。随着系统的扩充和发展，每个应用系统中都有独 立的用户账号，当用户需要使用网站的多个应用系统时，需要频繁的在各个系 统中进行登陆，没有一个整体的用户账号概念，进入每一个应用系统前都需要 以该应用系统的账号来登陆，这会给用户带来非常不方便的使用感受，用户会 想：既然我使用的是同一个信息系统中的应用，为什么不能经过一次登陆之后 就不必再经过应用系统认证直接进入应用系统呢？这样的困境尤其在 B/S 架构 的系统中经常会遇到。 单点登陆系统的应用前题条件是： 已经存在多个系统； 用户从一个系统访问到另外一个系统时需要登陆后才能访问资源。 已有的系统都各自维护自己的一套用户库，每个系统中的用户数、用 户名、密码几乎都各不相同。要将已有的用户库进行统一是不现实的。 因此，我们可以通过将单点登陆系统中的用户与其它个系统中的用户 建立映射，来实现用一个帐号来映射多个系统的目的； 单点登陆的应用要求是： 对已有的应用系统不作大规模改造。 开发单点登陆系统的难度不能太大。 已有的应用系统、以及待开发的应用系统，可能不在同一个域下，虽然会 话本身是保存在服务器端，但是会话 ID 是需要使用 Cookie 来传递的，而 Cookie 不允许跨域访问，而且考虑到各个系统的开发工具也各不相同，即使在 基于 Web Services 的统一权限系统第 3 章 新的解决方案分析 第 14 页 共 82 页 同一个域下，不同的开发工具所开发的应用程序之间也很难共享会话，因此要 用共享会话的方式来实现单点登陆也不现实。因此采用的方式是通过在客户端 浏览器、单点登陆系统和应用系统之间传递临时会话，并让应用系统直接到单 点登陆系统中获取认证信息来实现单点登陆，或使用数字证书来实现单点登录 3。 由此可见，单点登陆系统的应用领域主要是已存在的多个系统之间的身份 认证。主要解决在多个系统之间访问时不需要多次登陆的问题。各个系统都保 持自己的功能模块不变，只是在用户访问各系统时，在需要登陆的地方，由单 点登陆系统来自动处理登陆动作，并做相关信息的映射，简而言之就是自动登 陆。 而本文所提出的“统一权限系统”并不只是单点登陆。因为统一权限系统 除了单点登陆之外，更加关注的是对整个信息系统中权限的统一管理，而单点 登陆系统是不关心子系统权限管理问题的。 所以统一权限系统和单点登陆系统是不一样的。 3.3.2. 与与 Portal 门户系统的比较门户系统的比较 Portal 是基于 WEB 的应用程序, 它将不同资源进行整合并展现给用户。通 常其有如下三个特点: Personalization (个性化) Single sign on (单点登陆) Content aggregation (内容聚合) 其中 Content aggregation 指的是将不同来源的信息整合到一个页面中， 让用户更方便的使用. 比如, 如果某客户需要进行一次商业采购,以往需要访问不同供应商的主页 得到相关信息, 但如果使用 Portal 将所有不同的货物供应商的商品目录页面都 整合到一个 Portal 页面中, 那么对所有的商品信息就可以更快的浏览、筛选和 定货, 加快了客户的商业运作效率。 由此可见，Portal 系统关注的也是已存在系统间信息的整合，它并不影响 或改变已存在的系统，只是通过一种机制，让用户能在一个页面中集成更多系 统的信息，并能在各系统之间顺利的访问4。 而本文所提出的“统一权限系统”主要的应用时期是在系统建立之初，主 要的作用是将它作为一个基础的权限管理框架，其他业务系统的权限控制是在 这个基础之上建立而成，所以业务系统对统一权限系统是依赖关系，离开了统 一权限系统，业务系统就无法正常使用。它的主要目的是建立一个更方便操作、 基于 Web Services 的统一权限系统第 3 章 新的解决方案分析 第 15 页 共 82 页 更容易维护、更容易扩展的的权限管理和控制框架，而不是整合已存在业务系 统的数据。虽然“统一权限系统”也提供将已存在业务系统的权限管理加入到 统一权限系统中的方式和接口，但要求对已有业务系统的权限管理模块做部分 的改动，而且改动的规模大小要视子系统的具体情况而定，对“统一权限系统” 来说这是一个未知的因素，所以这并不是“统一权限系统”要解决的主要问题， 本文也不推荐这样做，只是在已存在业务系统必须加入到“统一权限系统”中， 是非改不可的，并且对所进行的修改在技术上是可行的情况下才这样做。也就 是说“统一权限系统”提供方式和接口，但并不推荐使用。 所以统一权限系统要解决的问题和 Portal 系统也是不一样的。 3.3.3. 比较的结论比较的结论 由以上比较可知，其他类似系统的主要关注点是对数据的整合5，而统一 权限系统的主要关注点是功能的整合，目的是改变目前权限管理的模式，实现 一个新的权限管理框架，让权限的管理更加全局化，让维护和扩展更加容易。 所以本文的创新点在于提出并实现了一个新的权限管理框架“统一权 限系统” 。 基于 Web Services 的统一权限系统第 4 章 统一权限系统的设计 第 16 页 共 82 页 第第 4 章章统一权限系统的设计统一权限系统的设计 4.1.4.1.设计目标设计目标 “统一权限系统”作为各业务系统的基础，提供统一的身份认证及权限管 理。建立角色、功能、范围、时间四个维度的抽象模型，统一管理所有的用户、 所有的模块和功能、所有的权限信息等。让业务系统将精力全部放在业务功能 的实现上，而将用户及其权限方面的实现细节，全部交给“统一权限系统”去 完成。 4.2.4.2.统一权限系统与业务系统的关系统一权限系统与业务系统的关系 统一权限系统和业务系统之间是依赖和被依赖的关系。每个业务系统都必 须依赖统一权限系统才能正常运行。对最终用户而言，统一权限系统和业务系 统是一个整体，不仅如此，对业务系统程序开发员而言，统一权限也是透明的， 他们只需要在自己的程序中调用统一权限系统客户端接口即可，并不需要知道 统一权限系统是如何实现的。 4.3.4.3.权限控制的方式权限控制的方式 4.3.1. 注册业务系统注册业务系统 每个业务系统及其功能操作都必须在“统一权限系统”中注册，注册层次 分为三级结构： 系统 所有需要进行权限控制的业务系统都必须在统一权限中注册，并获得唯一 的业务系统序号，本文称之为 SystemID。 SystemID 是两位数字，其可取值范围规定为 1099。 在管理员注册业务系统时，系统将自动计算一个可以使用的 ID 供管理员选 择，同时管理员也可以自己填写 SystemID，提交后系统自动判断该 SystemID 是否已经被使用，如果是，则提示管理员换一个 SystemID；如果否，则注册成 功。 模块 业务系统中的所有模块都要在统一权限系统中对应的系统下注册，并获得 基于 Web Services 的统一权限系统第 4 章 统一权限系统的设计 第 17 页 共 82 页 唯一的模块序号，本文称之为 ModuleID。模块是属于某个系统的。 模块序号是五位数字，由两位业务系统序号和三位模块流水号组成，如下： ModuleID=SystemID+三位流水号，如 10001，11056 等。 操作 业务系统中的所有操作都要在统一权限系统中对应的模块下注册，并获得 唯一的操作序号，本文称之为 OprationID。操作是属于某个模块的，操作是最 终节点（即树的叶子节点） 。操作由语义表示其具体的功能，如“增加公告” ， “修改公告”等。 操作序号是八位数字，由五位模块流水号和三位流水号组成，如下： OprationID=ModuleID+三位流水号，如 10001001，11056009 等。 4.3.2.权限控制的基本方式权限控制的基本方式 业务系统通过调用统一权限系统客户端 jar 包中的对象的方法来判断用户 是否拥有某个操作的权限，比如客户端 jar 包中的 WSAuthority 对象负责权限 认证，其方法 isUserCanOperate(int userID, String oprationID)方法用来 判断用户是否拥有某个操作的权限，则业务系统编程人员只要调用该方法，传 入用户 ID（userID）和操作 ID（oprationID）两个参数，则会得到结果。统一 权限系统客户端 jar 包的具体运行细节将在后文讨论。 4.3.3. 系统基本权限系统基本权限 如果只是简单的使用 OprationID 来判断权限，会很不方便。因为业务系统 中每个模块都会有浏览、增加、删除、修改等基本操作，如果业务系统采用 OprationID 来判断权限，那每个模块都需要记住大量的操作 ID，这对于业务系 统来说是不方便的。而且对于统一权限系统管理员来说，每增加一个业务系统 操作都要通知业务系统的开发人员，让其代码功能和 OprationID 文字所代表的 功能相对应，这是极其不方便的，而且也业务系统的编程人员也很容易产生错 误，比如 OprationID 写错了。 为解决这个问题，使权限的维护和使用更加方便，统一权限系统中保留了 一些基本权限，如浏览，增加，删除，修改、授权、统计等。本文称这些权限 为“基本权限” ，基本权限的语义是不会改变的，作为系统的默认数据存储在数 据库中。每个基本权限都有一个“基本权限代码”, 本文称之为 BaseRightCode，用来让业务系统编程人员更好的识别和使用该权限，比如“增 基于 Web Services 的统一权限系统第 4 章 统一权限系统的设计 第 18 页 共 82 页 加”的基本权限代码是“A”,“删除”的基本权限代码是“D”等等。 4.3.4. 改进后权限控制方式改进后权限控制方式 当管理员增加业务系统操作后，可以选择将该操作与基本权限做对应，如 果做了对应，业务系统编程人员就可用客户端 jar 包中 WSAuthority 的 isUserCanOperate(int userID, String moduleID, String baseRightCode)方 法来判断用户是否拥有某个模块的某个基本操作的权限，只需传入用户 ID（userID） 、模块 ID（moduleID）和基本权限代码（baseRightCode）三个参 数，即可得到结果。比如业务系统公告模块（ModuleId=10001）的“增加公告” 操作与基本权限中的“增加”(BaseRightCode=A)做了对应，则业务系统编程人 员可以按如下方式判断用户（UserID=255）是否拥有公告模块增加的权限： Boolean isCan=isUserCanOperate(255,“10001“ ,“A“); 而且该方法中的基本权限代码（baseRightCode）参数还可以是基本权限代 码的组合形式，如“A/D/M” ，各基本权限代码之间用“/”格开。 业务系统模块的基本操作，如浏览、增加、删除、修改等还必须在统一权 限系统中注册，因为在统一权限系统中，操作是分配权限的最小单位，每个操 作必须有一个唯一的 ID。但该基本操作的注册过程可以由系统自动完成。在增 加业务系统模块时，自动为模块增加基本权限对应的操作。 采用这样的方式之后，业务系统编程人员就不需要记住基本权限操作的 ID，而在实际使用过程中，大量注册的业务系统的操作都是基本权限的操作， 只有部分特殊的应用，会有些特殊的操作，这也在一定程度上降低了统一权限 系统和业务系统的耦合度。同时这种方式也将统一权限系统中注册的业务系统 的操作从语义中分离出来，因为注册的操作具体对应的功能是由操作的文字来 表示的，与基本权限做了关联之后，不再使用 OprationID 去判断权限，所以也 就与 OprationID 的文字没有关系了。 4.4.4.4.基于角色的权限管理基于角色的权限管理 4.4.1. 用户用户 系统的最终使用者是用户，因此必须建立用户的鉴别机构，登记用户的身 份信息。在系统中定义可登陆的用户操作系统是系统安全管理所必须步骤，也 是人与系统的接口。 用户代表了实际的系统使用者，在设计里并不只是代表某个业务系统的用 基于 Web Services 的统一权限系统第 4 章 统一权限系统的设计 第 19 页 共 82 页 户而是代表了全部系统的用户，权限管理模块是整个信息系统中唯一的用户信 息中心，在各个系统中将不保留用户以及权限的设置，全部由目前设计的权限 管理中心管理，各个平台系统通过 XML WEB Service 的接口取得用户以及权限 信息。模块带有的管理界面负责管理全部系统的用户信息操作。 用户本身不直接牵涉权限，权限全部由角色来的表示，角色是拥有权限的 最小单元。角色是对用户进行的分组，角色和用户之间是多对多的关系。角色 与角色之间有层级关系。角色中有一个特殊的角色，即用户代表角色：是角色 的一种特例，只用来代表用户自身。在分配权限时，可以将用户和角色都看作 是角色，采用相同的处理方式。 用户和角色之间的关系是多对多的：一个用户可以对应多个角色，一个角 色也可以对应多个用户，利用对照表的形式提供这种对应关系。 4.4.2. 角色角色 角色是整个模块中的中的重点，所有与权限（包括功能权限以及记录权限） 有关的信息都只与角色有关。角色有上下级关系，以及角色向下级权限分配代 理权限的功能。角色有上下级关系：模块将返回角色之间的上下级关系但是具 体上级角色可以使用下级权限到如何程度，模块不定义，由各个调用的系统内 部定义。角色代理：提供将自己的角色权限的全部或者部分提供给同角色组中 其它人的功能,代理是有时间限制的。并且系统提供统一的界面来设置代理。这 个页面实际运行在权限模块的服务器上，页面接受参数以获知设置代理用户的 信息，以及提供正确的可分配的代理用户信息6。 基于 Web Services 的统一权限系统第 4 章 统一权限系统的设计 第 20 页 共 82 页 一 一 一 一 一 一 一 一 一 一 一 一一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 基于角色的访问控制方法的思想就是把对用户的授权分成两部份，用角色 来充当用户行驶权限的中介。这样，用户与角色之间以及角色与权限之间就形 成了两个多对多的关系。系统提供角色定义工具允许用户根据自己的需要（职 权、职位以及分担的权利和责任）定义相应的角色。角色之间有相应继承的关 系，当一个角色 r1 继承另一个角色 r2 时，r1 就自动拥有了 r2 的访问权限(表 示 r1-r2) 7。角色继承关系自然的反映了一个组织内部权利和责任的关系， 为方便权限管理提供了帮助。角色继承关系提供了对已有角色的扩充和分类的 手段，使定义新的角色可以在已有角色的基础上进行，扩充就是通过增加父角 色的权限去定义子角色，分类通过不同子角色继承同一父角色来体现。另外还 允许多继承，即一个角色继承多个父角色，多继承体现对角色的综合能力。角 色定义流程如图 4.1 如示： 图 4.1：角色定义活动图 基于 Web Services 的统一权限系统第 4 章 统一权限系统的设计 第 21 页 共 82 页 4.4.3. 权限配置权限配置 角色是一组访问权限的集合，一个用户可以是很多角色的成员，一个角色 也可以有很多个权限，而一个权限也可以重复配置于多个角色。权限配置工作 是组织角色的权限的工作步骤之一，只有角色具有相应的权限后用户委派才能 具有实际意义8。权限配置流程如图 4.2 所示： 图 4.2：权限配置活动图 4.4.4. 权限一览权限一览 在授权完成后可检查登陆用户所的拥有的能力表信息，审查给用户的权限 是否合适，如不合适可重新进行用户委派和收回部分权限的处理。 4.4.5. 用户鉴别用户鉴别 安全保护的首要问题是鉴别用户身份。目前有三种方法可用：第一、利用 用户的物理特征（声波、指纹、相貌、签名） 。这在理论是最可靠的，但由于物 理特征可能随时间变化且记录尚欠成熟等原因，使该方法未能广泛应用。第二、 利用用户特有的证件，如身份证、机器可读卡先考片，其缺点是证件可能被别 一 一 一 一 一 一 一 一 一 一一 一 一 一 一 一 一 一 一 一 一 一一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 基于 Web Services 的统一权限系统第 4 章 统一权限系统的设计 第 22 页 共 82 页 人复制或冒用。第三、利用用户知道的某件能证明其身份的约定（如口令） 。这 是当前较为常用的方法。本系统采用第三种方法。 用户鉴别机构保存的一张登记有每个用户名称、标识和有关情况的表，表 中的用户名通常是公开的，标识则是保密的，当用户要访问系统时，须首先把 自已的名称和标识登记到系统中（即出示证件） 。这时用户鉴别系统机构检查用 户的标识是否与用表中的标识一致，是则认为用户身份己得到证实，否则认为 是假冒，系统将拒绝用户要求执行的操作9。口令是最常用的一种标识，通常 由若干字母、数字组合而成。系统只允许用户连续两次或三次登记口令，如果 都不对则要等待一段较长的时间才成重新登记，这种延长时间的方法能够有效 的防止冒名者猜测口令的可能。 4.4.6. 访问控制机构访问控制机构 杜绝对系统非法访问主要方法是访问控制。用户系统的访问可以用访问规 则表示，根据安全策略用访问规则给 0 用户授权。访问控制就是要处理怎样表 达和核对访问规则的问题。从形式上来说，一条访问规则可以写成四元组的形 式(u,o,t,p)可前已有权限表示形式重新表示为（u,P） 。系统的访问控制分为模 块级控制和界面元素级控制10。 存贮和检查访问规则是访问控制机构须解决的部问题。本系统为考虑运行 速度根据系统中角色、权限配置、用户委派等关系动态地的组成一张用户能力 表保存在系统中根据上述配置信息改变由系统动态生成和保存。能力表（也称 C-表）是存贮和核对访问规则的一种有效形式。能力表是面向主体的，用以说 明主体能对那个访问对象执行何种操作。 4.5.4.5.领域模型领域模型 从统一权限系统领域中识别出如下的概念类， 帐号（Account）：是所有业务系统中的用户的集合，将与统一权限系 统中的用户做关联。 用户（User）：系统中的行为者。一个用户可以关联多个帐号。采用 统一权限系统后，每个用户的身份是唯一的，并和已存在的业务系统 中帐号做映射。 角色（Role）：是对用户进行的分组，角色和用户之间是多对多的关 系。角色与角色之间有层级关系。角色是拥有权限的最小单元。 基于 Web Services 的统一权限系统第 4 章 统一权限系统的设计 第 23 页 共 82 页 用户代表角色（UserRole）：是角色的一种特例，只用来代表用户自 身。在分配权限时，可以将用户和角色都看作是角色，采用相同的处 理方式。 操作（Operator）：是具体的业务动作，即“做什么事情” ，如增加公 告，修改公告，删除公告等等。 范围（Range）：是操作的作用域，作用域可以是任何一个或多个角色。 即“对哪些对象做事情” ，如增加哪个部门的公告，或修改哪个部门的 公告。 时间：是控制角色拥有功能的期限，或功能的作用域的期限。 实际作用时间：是指操作实际起作用的时间。 权限数据：是操作、范围、时间的综合体。用来表示“用户在什么时 间什么范围内能做什么操作” 。 添加关联和属性，创建领域模型11如图 4.3 所示： 图 4.3：统一权限系统领域模型 4.6.4.6. 系统权限认证流程系统权限认证流程 用户通过统一权限系统提供的单一入口登陆，获得用户瘦令牌（令牌问题 将在后文中详细讨论） 。当用户访问业务系统时，业务系统首先判断用户的瘦令 牌中是否有相关的权限数据，如果没有，则访问统一权限系统获取权限数据； 如果有，则直接取出，然后验证权限数据来决定是否执行操作。采用 UML 活动 图的泳道可以清楚的表示这个过程12，流程如图 4.4 所示： 基于 Web Services 的统一权限系统第 4 章 统一权限系统的设计 第 24 页 共 82 页 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 Web Services一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一