统一集成范文（精选4篇）
统一集成 第1篇
统一通信 (Unified Communication, 简称UC) 是以IP通信为基础, 以VoIP、视频通信、多媒体会议、协同办公、通信录以及即时通信等为核心业务能力, 通过多样化的终端, 以IP为核心的统一控制和承载网以及融合的业务平台实现各类通信的统一和用户体验的统一。
在SOA、SaaS环境下, 要求系统能够提供多租户和可伸缩的支撑和管理服务, 这是对系统很高的要求。为满足这些要求, 需要作技术方面的努力, 但更重要的是在系统的架构和方法论方面作深入的工作。
1总体框架
本框架由接入服务器、MQ (Message Queue) 集群、AppContainer服务组成。本框架结构如图1。
1.1接入服务器
接入服务器不仅是通信平台的入口, 在业务的集成方面, 接入服务器提供一个插件接口。其中插件对插件接口的主要实现步骤为:①注册第三方集成业务的命名空间;②与MQ集群建立JMS连接, 建立MQ连接;③对客户端的消息和MQ集群中的JMS消息进行监听, 解析收到的消息并封装;④将来自MQ集群的消息发送给客户终端, 将来自客户端的消息发送给MQ集群。
1.2MQ集群
位于同一个群集当中的若干队列管理器之间互相通讯时, 不需要在每一个队列管理器上创建消息通道、远程队列管理器以及与通道相关的传输队列的定义。因此, 采用MQ集群技术大大简化了平台的配置, 并且当某一系统或网络出现故障时, 能够自动进行负载均衡, 同时同一集群中的服务器可以位于不同的平台和物理位置, 使得平台的管理更加简单高效。
1.3AppContainer服务
AppContainer服务是基于OSGi服务框架实现的, OSGi服务框架提供一个通用的、安全的、可管理的Java框架。在OSGi中, 模块被称为Bundle, 是能够对外提供服务的构件, 由普通的JAR文件加上额外的元信息描述构成的。在OSGi服务中, 用户通过开发Bundle来提供所需的功能, 这些Bundle可以动态加载和卸载, 或者根据需要远程下载和更新。
2框架实现方法
2.1基于OSGi的AppContainer服务
出于平台的易扩展性与定义信息的统一传输链路的考虑, 抽象出以下Bundle:
(1) 接口服务Bundle定义了一组服务接口:JMS消息服务接口、消息处理接口、执行业务服务接口和线程池服务接口、以及对外提供统一的服务接口等。这些服务接口定义了AppContainer服务中的Bundle对各自的业务处理所需要的所有服务, 对这些接口中所有方法的说明如下:
①消息处理接口:定义了对接收到消息进行处理的方法。Java描述如下:
(2) JMS Bundle是对接口服务Bundle中JMS消息服务接口的实现, 其主要职能是负责AppContainer服务中消息的接收和发送。对JMS Bundle职能的具体说明如下:①建立JMS连接、连接MQ, 并对MQ的连接进行监听, 若断线则立即重连;②对JMS消息进行监听, 若接收到JMS消息, 则调用线程池服务, 开启一个线程;③在该线程中调用消息服务, 将消息发送至服务控制Bundle中继续处理;④将消息封装成JMS消息发布到MQ集群中。
(3) 服务控制Bundle是对接口服务Bundle中消息服务接口与对外统一服务接口的实现, 其主要职能是根据命名空间分发消息请求到对应的业务Bundle去处理。对服务控制Bundle职能的具体说明如下:①绑定对外统一服务接口的地址;②接收到主动查询请求消息, 解析出消息中的命名空间, 根据命名空间将查询请求消息分发至相应的集成业务Bundle去处理;③接收到推送服务请求, 解析出命名空间, 并从线程池中启动一个线程, 在该线程内, 完成业务的分发、集成业务Bundle对业务的处理以及向MQ集群的推送服务。
(4) 线程池Bundle是对接口服务Bundle中线程池服务接口的实现, 其职能利用线程池来控制线程的数量, 避免平台资源的浪费, 提高平台系统的工作效率。
(5) 集成业务Bundle代表了所有可集成到平台中的业务Bundle。通过开发第三方业务Bundle, 来达到平台对第三方业务集成的目的。具体工作方式如下:①接收到主动查询请求消息, 解析查询请求, 并通过解析结果同对应的第三方业务系统进行交互并进行业务的查询, 并将查询结果返回给JMS Bundle处理;②接收到推送请求消息, 将消息封装成XML消息流, 然后将结果返回给JMS Bundle处理。
抽象出的Bundle结构如图2所示:
AppContainer基于OSGi的特性与支持服务的分发功能保证了第三方业务Bundle能在本平台上热插拔, 同时决定了第三方集成业务能够在平台正常运行的过程中与平台进行动态的集成。
2.2高负载支持
MQ集群技术提供异步的、非阻塞的消息传递。即发送方可即时将消息放入消息队列, 而接收方也能随时从队列中取出消息进行处理。这样避免了双方直接接触保证了任何一方发生脱机时消息都不会丢失。这种可靠的、松耦合的消息传输方式, 在分布式环境下进行多数据的发送和接收时依然能够稳定可靠地通信。
针对与需要不断集成的第三方业务, 部署多个AppContainer服务模块, 将集成业务Bundle平均部署到每个AppContainer服务中, 以此缓解平台压力。
2.3统一接口
每种业务系统都存在着自己定义的用户接口, 进行集成时, 为实现接口的容错处理机制, 避免因为一个系统的接口中断而影响到其它应用系统的接口, 平台向外提供了统一的服务接口, 与第三方业务进行交互。根据不同应用服务的需要, 统一的接口包括:RMI (Remote Method Invocation, 远程方法调用) 接口、Web Service接口、JMS接口等。
统一的接口对业务的集成而言, 简化了集成方式, 方便了维护方法, 实现了接口的可重用性和可管理性。
3集成实例
在本框架下, 我们将此平台与办公自动化 (OA) 业务进行集成实验。开发者仅需要开发接入服务器插件和OA业务Bundle即可实现平台与OA业务的集成。接入服务器中OA插件主要做以下方面的工作:
(1) 注册请求OA消息的命名空间。
(2) 对客户终端的请求消息进行监听, 若与命名空间匹配, 则解析出消息内容, 并封装成JMS消息发布到MQ集群中, 客户终端的XML消息格式如下所示:
(3) 对MQ集群中的消息进行监听, 若监听到发送给客户终端的消息, 则将消息解析出来, 封装成与客户终端交互的消息格式, 发送给客户终端。解析出来发送给客户终端的XML消息格式如下:
(1) 根据查询请求中的信息登录到OA系统, 查询待办项目或通知的个数。
(2) 将推送消息解析封装, 并将封装结果返回给JMS Bundle。
在AppContainer服务中的流程分为主动查询流程和推送流程, 主动查询流程描述如下:①JMS Bundle监听到MQ中有查询OA待办项的请求消息;②JMS Bundle从线程池中启动一个线程, 然后在此线程中, 将此查询请求消息发送至服务控制Bundle中;③服务控制Bundle获取并匹配OA业务的命名空间, 然后分发到OA业务Bundle中;④OA业务Bundle向OA系统进行待办项数目的查询, 并将查询结果返还给JMS Bundle。该Bundle将结果封装成JMS消息发布到MQ集群中。
最后由接入服务器的OA插件从MQ中提取到查询结果, 并将查询结果返还给客户终端。具体流程如图3所示:
推送流程描述如下:①OA业务系统调用平台提供的RMI接口将待办或通知的个数消息发送到平台的AppContainer服务中;②服务控制Bundle获取该消息并根据命名空间进行匹配, 匹配成功后启动一个线程, 在此线程内, 将消息分发到OA业务Bundle中;③OA Bundle通过接口服务提供的JMS消息服务接口调用JMS Bundle中的发送JMS消息方法, 将消息封装成JMS消息, 并发布到MQ集群中。
最后接入服务器中的OA插件从MQ中获取推送消息后, 发送给客户终端。具体流程如图4。
4结语
本文提出的统一通信平台集成框架对私有协议、消息格式和通信链路不同的办公应用进行了研究, 为构建一个扩展性好、重用性高、通信链路统一、支持大并发的统一通信平台提供了一个新的解决方案, 在企业的多个系统中搭建了一座信息的桥梁, 实现了信息的互通和共享, 为企业的协同作业提供了技术支持。更重要的是为用户提供了一个桌面门户和平台, 为其它的企业应用提供了一个统一的入口端。不仅如此, 在该框架下, JMS消息链路和MQ连接的建立都可以重复使用, 因此对第三方企业业务进行集成的开发效率上也有较大提高。
参考文献
[1]江志峰.从统一通信看IMS的发展[J].电信科学, 2008 (2) .
[2]闵丽娟, 朱珠, 娄高见, 等.开放信息服务的运营支撑和服务管理系统[J].电信科学, 2011 (11) .
[3]吴成宾, 朱彬.基于MQ的文件分片传输系统的设计与实现[J].电子科技大学学报, 2007 (3) .
统一身份认证的集成解决方案研究 第2篇
随着面向用户需要安全保护的应用服务系统不断增加, 而用户面对的不同应用服务系统的安全认证并不是采用统一的一套安全口令, 这使得用户在访问这些应用时变得越来越繁琐, 并且必须记忆多套安全口令。统一身份认证服务从根本上解决了这一问题, 并且用户只需要进行一次认证就可以实现在各个应用服务系统间的访问。统一身份认证系统与各应用服务系统的集成是实现统一身份认证的关键一步, 但是, 由于各应用服务系统采取的技术差异 (或结构差异) 使得将它们与统一身份认证服务集成带来困难。针对这一情况, 在不同的应用场景下, 本文提出了几种可行的集成解决方案。由于实际应用中基于桌面的应用服务系统并不多见, 因此本文只讨论身份认证服务系统与基于WEB的应用服务系统的集成。
1 统一身份认简介
统一身份认证的功能主要是提供单点登录服务 (Single Sign-On) 和会话管理服务, 是企业 (或其他部门) 信息化建设的重要基础。通过统一身份认证的用户管理, 有助于改变各信息化应用服务系统松散、孤立的管理方式, 同时有效解决了用户身份分散管理带来的安全管理问题, 消除了用户多次登录造成的不便, 提高了用户可操作性, 降低了信息系统的管理难度。
统一身份认证系统一般由用户身份数据中心、身份管理系统 (IM Identity Manager) 、访问控制系统 (AM Access Manager) 组成。用户身份数据中心包括目录服务器LDAP (主要存储用户认证信息及权限信息) 和数据库 (作为扩展来存储用户身份属性信息) 。身份管理系统 (IM) 用来实现用户的身份信息的维护, 包括用户管理、身份配给、自动发现、口令管理、权限管理等内容。访问控制系统 (AM) 主要实现统一认证及单点登录。
2 集成方案
2.1 与可改造的应用服务系统的集成
可改造的应用服务系统是指可以自由开发或者容易对其进行改造的应用系统, 这类系统一般采取了开源的技术, 不涉及到秘密技术, 没有自己的认证机制或者自身的认证机制容易改造。针对这类应用, 我们可以采用基于面向对象的中间件ICE来提供一个认证服务接口, 通过对外暴露一个端口实现应用服务系统与统一身份认证服务系统的交互。
ICE (Internet Communications Engine) 是一种现代的面向对象的中间件平台。它为构建面向对象的客户端/服务器 (C/S) 应用提供了工具、API和库支持, 客户端和服务器的开发可以使用不同的编程语言, 适用于异构环境。它的优点是:客户端和服务器可以分别运行在不同的操作系统和硬件架构上;可以使用多种网络技术进行通信;无论部署环境如何, 其应用程序代码都可移植[1]。
图1展示了这种集成方案的逻辑架构:
通过 ICE 实现应用服务与统一身份认证服务集成有如下优点: (1) ICE是轻量级的消息交互中间件, 部署简便, 可以有效解决网络负载方面的性能瓶颈问题。 (2) 客户端类型丰富, 能最大范围满足异构应用服务集成的技术实现。 (3) 采用SSL进行通信强加密, 可以使客户端和服务器安全地进行通信。 (4) 由于在ICE架构中运用了对象模型, 使用XML的对象自动持续, 使其具有很高的运行效率。且可在接口中定义任意操作, 所以在部署应用中可以灵活运用接口来进行认证操作。 (5) 采用了标准的SLICE规范接口语言和自带的SLICE编译器, 其开发不受开发语言以及操作系统平台的限制, 同时ICE是可移植的, 同一源码能够在Windows、Linux以及 UNIX 等不同的系统平台上编译和运行, 这样既改善了异构兼容性, 还降低了开发难度, 易于实现[1,2]。
当然, 这种集成解决方案有一定的局限性:被集成的应用系统必须是易改造的。如被集成的应用系统改造困难, 比如像Microsoft的Exchange这样的封闭的邮件服务系统, 它有自己的认证机制, 几乎不可改造, 或要付出相当高的成本。显然, 在这种情况下, 此集成方案失去了它的意义。
2.2 与不可改造的应用服务系统的集成
在实际的应用中要与统一身份认证服务系统集成的往往是一些公司的产品, 这些产品一般不会对外提供源代码, 在设计这些产品时也没有考虑到与第三方的统一身份认证服务系统的集成。像这样的系统一般情况下加以改造是非常困难的, 但是我们又不得不把它和统一身份认证服务系统集成。针对这类应用的集成, 还有必要区分, 是否有自身的认证机制。
这类应用服务系统的集成我们采取的方式是代理。不管什么应用, 它们必须通过Http Server来向外提供WEB访问, 比如Microsoft的Exchange需要IIS (Internet Information Service) 才能运行。采用基于Agent的技术统一身份认证可以解决这类问题[3]。通过在Http Server上安插拦截器来拦截被保护的访问请求来达到集成的目的, 这里称这种拦截器叫做 Web Agent。针对不同类型的 Http Server 的 Web Agent 的实现细节是不同的, 但是他们提供的功能是一致的。针对“是否有自身的认证机制”这一差异, 下面给出两种集成方案。
与自身没有认证机制的应用服务系统的集成, 其集成逻辑架构见图2。
与自身有认证机制的应用服务系统的集成, 其集成逻辑架构见图3:
比较以上两种集成的方式, 第一种集成方式是比较简单的, 这种方式下, 当用户访问受保护的应用服务系统时, Web Agent会拦截用户的访问请求, 并通过与统一身份认证服务进行通信来检查用户的合法性[3], 如果用户已经经过了合法认证则允许用户访问, 否则用户被重定向到统一身份认证服务进行认证后再访问受保护的应用服务。而第二种集成方式相对复杂一些, Web Agent不仅要检查用户的合法性, 还必须自动为用户到受保护的应用系统的认证机制进行认证, 这个认证过程对用户来说是不可见的, 整个过程用户只需在统一身份认证服务认证一次。这里将出现一个不可回避的问题:由于实际上进行了两次身份认证, 两次认证用户是同一身份, 这就涉及到两个目录服务中的用户数据一致的问题。因此, 第二种集成方案必须是建立在身份认证的目录服务与受保护应用服务的目录服务的数据同步的基础之上。
与前面可改造的应用服务系统的集成方案不同的是, 本节提出的集成方案中认证模块不再嵌入到应用服务系统的本身, 因此不需要修改应用服务系统的代码, 并且认证模块靠向了Http Server。它突出的优点表现在: (1) 现在大部分统一身份认证服务产品厂商提供了这种Web Agent, 不需要进行二次开发, 节省了集成的成本; (2) 通过配置可以有选择地拦截应用服务资源, 提高了集成的灵活性; (3) 原来的应用服务系统安全性不会受到任何影响 (保留了原来的认证机制) , 保证了其原来的安全特性。
当然这种集成方案有一定的缺陷: (1) 由于会对应用资源进行拦截以检查合法性, 这将加大 Http Server的压力, 对原来的性能会有一定的影响, 这是必然的; (2) 必须考虑应用服务系统自身的认证机制, 需要对数据进行同步。
2.3 与特殊应用服务系统的集成
还有一种比较特殊的应用场景, 比如某高校的选课系统, 特点是在短时间内会涌现数量巨大的认证请求。像这种高并发性的请求, 如果采取普通的集成方式, 显然不能满足用户的需求, 严重时将导致身份认证服务系统当机。为了解决这个问题保证性能, 只有放弃身份认证服务提供的SSO服务, 也不再对用户会话进行管理, 而是直接进行身份认证。下面就针对这种场景的集成进行说明。
图4是身份认证服务与高并发认证请求的应用服务的集成逻辑结构, 实际上这种集成只是单纯的认证集成, 没有提供SSO服务和会话管理服务。这种集成的关键是身份认证服务提供的一些核心API, 而不是身份认证服务本身。如图4所示, 通过API函数, 应用服务可以直接和LDAP目录服务进行通信, 从而用户身份可以通过使用这些API函数直接进行认证, 无需通过统一身份认证服务来进行认证。
这种集成方案的优点是显而易见的:能够处理高并发性的认证请求。但是有着不可调和的矛盾:抛弃了SSO以及管理会话。总的来说, 这种应用场景还是比较特殊的, 不会存在很长的时间 (比如高校选课不会有很长的时间) , 这种解决方案应该是符合实际的需求的。
3 实验
3.1 实验环境
实验环境如下:身份认证服务采用Sun Java Enterprise System 2005Q4中的Access Manager, Access Manager已经升级至Patch09, 运行在RedHat AS 4U7 (x86) ;开发好的ICE Server以及ICE Client, 客户端包含Java和ASP客户端; Oracle Application Server 10g Portal 等等。
3.2 与可改造的应用服务系统的集成实验
实验采用ICE中间件技术开发的ICE Server。配置好ICE Server, 建立好与AM的通信并让它监听在2000端口上。这里用一个简单的静态页面表示被保护的应用服务, 用以模拟可改造的应用服务。
对于Java应用, 使用开发好的Java版本的 ICE Client, 配置好与ICE Server的通信 (配置ICE Server所在机器的IP以及监听的端口等等) , 通过创建ICE Client提供的认证管理器 (Identity Manager) 对象就可以直接调用封装好的方法了。用户访问时其会话信息被保存在浏览器的Cookie中, 每次对受保护资源的请求都会被要求检查Cookie中的会话信息是否有效, 这些繁琐的操作现在只需要认证管理器对象就可以简单的实现了, 不必考虑如何与身份认证服务进行通信。对于ASP应用, 其配置也是一样的, 只是认证管理器不像在Java中那样创建, 必须将其注册为COM组件。注册成功后, 就可以通过操作认证管理器来保护受保护的资源了。为了测试集成是否成功, 先访问集成好的Java应用, 被定向到Access Manager 的认证界面, 输入正确的用户名密码认证通过后便顺利访问到了Java应用中的资源;在浏览器未关闭的情况下, 访问ASP应用, 这时直接进入而不需要进行认证。显然, 集成实现了SSO, 是非常成功的。复旦大学的门户系统是用该方式集成的典型案例 (Java版本) , 读者可以通过访问它来体验其中的过程。
3.3 与不可改造的应用服务系统的集成实验
这里选用 Oracle Application Server 10g Portal 进行集成实验。集成用到的 Web Agent是Sun Java System Access Manager Policy Agent 2.2 for Apache HTTP Server。在集成前, 访问Oracle Portal是需要进行认证的, Oracle Application Server有专门的认证服务 (Login Sever) , 所有的注册为合作伙伴的应用服务都会被定向到Login Server进行认证。这里要保护Login Server, 保护它就保护了所有的合作伙伴应用服务。
3.4 与特殊应用服务的集成实验
这种情况下的集成是比较简单的, 但是测试其处理高并发性认证请求的性能比较困难。但是在实际环境中有个很好的例子, 南京师范大学在2008年下学期的选课系统中采取的就是这种集成方式, 当时的请求量是非常巨大的, 粗略估计最高达到了近100次/秒, 虽然如此, 学生在选课时的登录响应很快, 身份认证服务所在机器的硬件资源占用也非常少, CPU在1%左右, 内存在1.2 GB左右, 可见这种集成方案在应对高并发请求时的优势。
4 结束语
应该说本文提出的集成方案几乎涵盖了全部实际应用情况, 可以顺利解决统一身份认证集成的大部分问题, 真正体现其“统一”的特性。当然, 仍有一些应用服务系统还无法与其进行集成, 比如笔者试图集成 PaperCut 产品, 使用上述集成方案都已失败而告终, 这说明应用服务系统本身对集成的支持是集成成败的关键。采取开源的, 透明的技术来开发应用系统将大大提高与统一身份认证集成的可能性, 也将大大节省集成的成本。
摘要：统一身份认证系统的目的是集成各种应用系统并实现统一身份认。针对应用服务系统的特点, 分别提出了三种集成方案, 基于ICE中间件技术的认证接口的集成方式能很好地解决易于改造的应用系统的集成问题, 而针对不易改造的应用系统提出了基于代理的集成方案, 最后提出了特殊应用场景下的集成方案。
关键词：统一身份认证,统一身份认证集成,ICE中间件,代理
参考文献
[1]李爱华, 徐立臻.基于ICE技术的身份认证交互模型.计算机应用, 2005; (3) :567—569
[2]孙超.异构集成环境下的统一身份认证系统.南京:东南大学.2006
[3]孙超, 陈钢.基于Agent技术的统一身份认证系统.计算机应用研究, 2005: (03) :138—140
统一集成 第3篇
一、EZproxy概述
二、用户身份统一认证
EZproxy灵活地提供了多种用户认证方式与外部数据库连接, 这样用户远程访问时便可使用现有身份认证系统中的信息, 不需要重新增加用户信息和密码。将EZproxy用户认证与图书馆现有集成管理系统中的用户管理模块结合起来大大节约了管理成本, 方便了用户使用, 提高了图书馆自动化管理水平。国外常见的认证方式有:连接如LDAP、Athens、Shibboleth等身份认证系统或基于SIP的Voyager系统等, 国内目前也已有湖南师范大学、浙江科技学院、浙江师范大学等对其进行研究, 已实现与ILASII系统等进行统一认证, 但基于SQL server数据库的图书馆集成管理系统与其进行连接目前未见诸文献。本文主要描述基于SQL server的金盘图书馆集成管理系统与EZproxy实现用户统一认证的方法。
三、功能实现
实现用户认证的第一步便是与SQLserver数据库进行连接。根据官方配置说明, 我们先建立ODBC系统DSN数据源。然后, 在外部认证脚本的sql语句中设置数据库名为上面所建的系统DSN名称, 设置具有使用数据库权限的用户名和密码。在查询语句中设置要查询的项目, 即用户表中的用户名称与密码, 如果为合法用户便向EZproxy返回有效标识。最后, 在EZproxy用户配置文件usr.txt中包含外部脚本, 如添加如下行:
其中, auth.youlib.org为认证服务器的地址, check.cgi为外部认证脚本文件, post表示用html的post方法将用户名和密码提交外部脚本进行认证, ^u自动替换登陆表单上的用户名, ^p自动替换密码。使用post方法的好处是避免web服务器记录用户信息。valid中指定的值“+OK”为用户认证成功后返回的有效标识, 认证脚本只要向Ezproxy系统返回valid参数所指定的有效标识, 则Ezproxy系统认为认证成功。
四、相关功能
1、分组认证。
EZproxy不仅能实现用户认证功能, 更可以允许实现用户分组认证, 如在配置文件config.txt文件中设置相应数据库访问权限后, 在usr.txt中添加:
::group=General
::file=general.txt
表示设置普通用户组General, 用户存储在文件general.txt中, 可以访问普通数据库。
::group=legal
::file=legal.txt
表示设置法律用户组, 可以访问法律类数据库。
::group=General+legal
::external=special.txt
表示设置用户组可以访问所有的数据库。
2、流量控制。
UsageLimit-enforce-interval=60-expires=360-MB=100Global。即针对所有数据库, 用户在60分钟内流量超过100MB时强迫冻结用户账号, 并于360分钟后自动解冻。
五、总结
目前, 我们已经实现了EZproxy与图书馆集成管理系统的统一认证, 已在遵义师范学院图书馆进行试用。但相关的上述功能还需进一步摸索, 相信不久的将来, 使用EZproxy能为广大读者提供更加完善的服务。
摘要：本文介绍了使用远程访问系统EZproxy与现有图书馆集成管理系统连接实现用户统一认证的过程, 旨在为使用相似系统环境的用户提供一些经验参考。
关键词：EZproxy,图书馆集成管理系统,用户统一认证
参考文献
[3]陈光锋.EZproxy在校外访问服务中的应用分析[J].图书馆学研究, 2008.10.
[4]田支斌.门户网站中集成ILASⅡ读者认证与EZproxy校外访问系统的研究[J].现代图书情报技术, 2009.5.
统一集成 第4篇
关键词：跨域,统一认证,访问控制,系统集成
1 引言
随着企业信息系统的快速发展,企业内部广泛存在不同架构、不同认证与访问控制策略与实现方式、基于域控和没基于域控等不同形式下的各类信息系统,表现出体系结构上的分布式、域内自治、域间协作等复杂应用系统的特征。 基于这些特征的信息系统面临着无法进行统一认证和访问控制、跨系统协同和系统集成困难的新问题和新挑战,具体表现:(1)申请访问各系统的主体来源不同,甚至具有临时性,往往是现有统一认证系统不认知和不能识别的;(2) 各个信息系统本身的访问控制策略和安全机制存在差异,表现在访问控制模型的异构性;(3) 已有信息系统的统一认证与访问控制存储方式多样化, 关系型数据库、LDAP目录树、Microsoft Active Directory(AD)等共存。 与此相关的研究主要集中在基于活动目录的认证系统等方面,较少关注跨域统一认证与系统集成方面的应用。
本文给出了跨域统一认证与系统集成应用场景,提出了一种跨域统一认证与系统集成方案,并结合企业应用进行了实践,解决了企业门户系统升级过程中的统一认证与系统集成问题。
2 跨域统一认证与访问控制体系结构
本文通过创建共享库, 以共享库为基础在共享库、Microsoft Active Directory (AD)、IBM Tivoli Directory Server LDAP目录服务之上搭建了跨域统一认证器,设计了一套认证流程,实现跨域统一认证,并在此基础上建立基于RBAC的访问控制策略,实现不同信息系统的统一认证与单点登录。 图1 给出了跨域统一认证与访问控制体系结构图,箭头指明了跨域统一认证与访问控制过程。 跨域统一认证与访问控制体系结构主要包含五个构件:(1)用户/ 角色管理器:对用户和角色进行管理,定义用户与角色的映射;(2)资源/ 操作管理器:对资源和操作进行管理,定义资源与角色的映射;(3)跨域认证器:依据不同用户来源,依据相应认证流程对访问主体进行身份验证;(4)安全控制器:对共享库、AD服务器及统一认证器进行监控及预警;(5)跨域同步/ 映射器:对域间用户/ 用户组/ 角色进行数据同步或进行不同层次和粒度的映射。
当某用户需要访问某项资源进行相关操作时, 生成一个访问请求,事实上将进入跨域统一认证器进行验证。
3 跨域统一认证与访问控制策略
3.1 跨域认证机制
跨域统一认证与访问控制的核心是跨域认证机制,下文结合统一认证过程对涉及到的共享库和跨域认证机制进行阐述。
3.1.1 共享库
共享库是对各个信息系统以数据库形式管理的用户/ 角色的抽象, 定义为所有非基于AD域验证的信息系统的用户/ 角色,既非域控用户/ 角色的集合。 它统一存储所有信息系统的用户信息,信息系统对用户信息的存储和管理全部通过共享库完成,而授权则由各信息系统完成,即统一存储、分布授权。 共享库具备几项基本功能:(1)用户信息规范命名、统一存储,用户ID全局惟一,用户ID犹如身份证,区分和标识了唯一的不同访问个体;(2)向各信息系统提供用户属性列表,如姓名、电话、地址和邮箱等属性,各信息系统可以选择本系统所需要的部分或全部属性;(3) 信息系统对用户基本信息的增加、修改、删除和查询等请求由它处理;(4)各信息系统保留用户管理功能,如用户分组、用户授权等功能;(5)具有完善的日志功能,详细记录各信息系统对它的操作。 共享库的主要用途是使非基于AD域验证的信息系统能够共享同一套用户/ 角色,实现访问主体的统一管理。
3.1.2 跨域认证机制
跨域认证有三种基本情况:一是某非域控用户(没有登入AD域的用户)请求访问非基于AD的域外资源(例如非基于域控的信息系统);二是非域控用户请求访问域内资源(例如基于域控的信息系统);三是域控用户请求访问域外资源(例如非基于域控的信息系统)。 第一种情况的难点在于域之间的用户信任问题;第二种情况的难点在于非域控用户无法得到域内资源的信任;第三种情况的难点在于域控用户无法得到非基于域控的资源的信任。 第一种情况可以使用单点登录技术。 单点登录(SSO,Single Sign-on)是一种方便用户访问多个系统的技术, 实质是安全上下文(Security Context) 或凭证(Credential)在多个应用系统之间的传递或共享。 目前业界已有很多产品支持SSO, 如IBM的Web Sphere和BEA的Web Logic,但各家SSO产品的实现方式也不尽相同。 Web Sphere通过Cookie记录认证信息,Web Logic则是通过Session共享认证信息。 Cookie方式可实现SSO,但域名必须相同;Session是一种服务器端机制,当客户端访问服务器时,服务器为客户端创建一个惟一的Session ID,以使在整个交互过程中始终保持状态,而交互的信息则可由应用自行指定, 因此用Session方式实现SSO,不能在多个浏览器之间实现单点登录,但却可以跨域。 同时,OASIS(结构化信息标准促进组织)提出了SAML解决方案。
上述方案都能很好地解决跨域认证的第一种情况并实现统一认证和访问控制。 但由于企业应用的多样性与复杂性,往往会出现前述的第二和第三种情况。 如图2 所示。
当非域控用户要访问域内资源时,域内资源要求提供相应域控用户账户和域口令进行验证,这时使用经跨域同步/ 映射器映射后的域控用户账户并搭配域口令去域服务器进行验证。 当域控用户请求访问域外资源(例如信息系统)时,这时使用经跨域同步/ 映射器映射后的共享库用户账户并搭配相应口令去共享库服务器进行验证。 这样通过跨域同步/ 映射器已完成域控用户与非域控用户的相互转换,实现跨域统一认证和访问控制。
3.2 跨域同步/ 映射机制
跨域统一认证与访问控制依赖于跨域同步/ 映射机制,跨域同步/ 映射机制是实现统一认证与访问控制前提,下文结合统一认证过程对跨域同步/ 映射机制进行阐述。
3.2.1 用户同步
新用户注册到共享库之后会自动同步到跨域统一认证器中,始终保持用户的一致。 如果域控用户是共享库用户的子集,域控用户访问域外资源将无需使用映射机制,如果共享库用户是域控用户的子集,共享库用户访问域内资源也无需使用映射机制,自然维护一对一映射关系。 通常情况下对于企业内应用,完全可以以共享库为基础,而域控用户维护为共享库用户的子集,这样当共享库用户访问域内资源时,此共享库用户在域服务器中不存在时使用映射机制。
3.2.2 域控用户与非域控用户映射粒度
AD域访问主体DU对非域内资源进行访问时通过跨域同步/ 映射器完成DU(域控用户)到非域内资源中访问主体SU(共享库用户)不同粒度的映射,包括AD域控用户组/ 角色到共享库角色(包括用户组/ 角色的用户直接到角色)的映射,对AD域访问主体聚类后再到共享库中角色的映射两种不同的映射粒度。 两种具体映射又设计了三种不同的方式:一对一、一对多、多对多。 这样就实现了AD域访问主体对共享库访问主体间映射的灵活多样,满足各种需求。
非域访问主体SU对域内资源进行访问时通过跨域同步/ 映射器完成AD域外非域访问主体SU(共享库用户,非域控用户)到AD域访问主体DU(域控用户)不同粒度的映射, 包括共享库用户组/ 角色到域控用户(包括用户组/ 角色的用户直接到角色)的映射,对共享库访问主体聚类后再到AD域中角色的映射,特殊的临时映射三种不同的映射粒度。 三种具体映射又设计了三种不同的方式:一对一、一对多、多对多。 这样就实现了共享库访问主体对AD域访问主体间映射的灵活多样,满足各种需求。
设计保持具体映射唯一性(同时同地只能激活一种粒度下的一种具体映射方式)以避免映射主体之间权限的重叠与互斥。
3.3 跨域统一认证与访问控制过程
本文提出的跨域统一认证与访问控制方案的主要特点是实现了域内外访问控制实现方式的统一,跨域认证过程中,消除了域内与域外的差别,使已有的各信息系统独立的认证与访问控制过程基于共享库实现统一认证,同时又可以集成基于AD域的信息系统实现统一认证, 便于将各类信息系统进行集成并实现单点登录。图3 给出了当用户需要访问某信息系统进行某种操作时的统一认证具体过程,首先提交用户认证信息给安全控制器预判涉及到的共享库和AD服务器是否正常,然后预判正常情况下将用户信息进一步提交跨域同步/映射器,跨域同步/ 映射器将依据用户信息判断是否需要映射并完成相应映射后提交给具体的验证服务,验证服务完成验证后将验证结果提交给将要访问的信息系统,信息系统根据用户即时授权,完成对相应操作或资源的访问。
4 应用案例
企业内实施了门户系统,整合了大量信息和企业内部信息系统,基本实现了信息系统单点登录和用户统一管理。 随着门户的深化应用,需要挂接和集成在门户上的信息系统类型和数量日益增加,其中门户系统上已有的信息系统采用基于数据库的统一用户管理系统实现了统一认证和单点登录,但是逐渐出现了基于AD域的信息系统需要挂接和集成在现有门户上,同时企业内客户端有可能使用域控用户登入域也有可能不登入域,不同类应用系统认证方式、访问控制策略和面向用户的差异,以及用户客户端的多样化对系统集成和单点登录带来了困难和挑战。 如果非域控用户SU(共享库用户)试图登录基于域验证的信息系统A,该用户只需要登录门户系统, 门户系统实现了跨域统一认证与访问控制,该用户登录门户系统即通过跨域同步/ 映射映射为相应域控用户DU,并提交DU给域服务器进行验证,如果验证通过,则提交DU给相应信息系统进行授权,如果成功授权,则SU可以对该信息系统进行相应操作,否则拒绝访问。 如果域控用户DU试图登录某非基于域的信息系统B,该用户也只需要登录门户系统,该用户登录门户系统即通过跨域同步/ 映射器映射为相应共享库用户SU,并提交SU给共享库服务器进行验证,如果验证通过,则提交SU给相应信息系统进行授权,如果成功授权,则DU可以对该信息系统进行相应操作,否则拒绝访问。
5 结束语
本文通过引入共享库和跨域映射机制,实现跨域统一认证和访问控制来解决企业内不同类信息系统认证方式、访问控制策略和面向用户差异及用户客户端多样化对系统集成和单点登录带来的问题,提出了可行的方案并进行了实现。 在今后的工作中,会更加深入的考虑通用性以扩展方案。
参考文献
[1]张冠东,王绪本.基于活动目录的域用户认证系统的研究和设计[J].微型电脑应用,2005,21(5):5-6.
[2]李志民.基于活动目录的访问控制系统设计[J].中原工学院学报,2004,15(2):33-35.
[3]于剑,张辉,赵红梅.LDAP目录服务在Web开发中的应用[J].计算机应用,2003,23(10):82-83.
[4]刘宏月,范九伦,马建峰.访问控制技术研究进展[J].小型微型计算机系统,2004,25(1):56-59.
[5]林满山,郭荷清.单点登录技术的现状及发展[J].计算机应用,2004,24(zl):248-250.