大规模信息系统应用中的用户集成策略与实现

陈 炜，柯水洲，李 强

（1.河北农业大学人事处，河北保定 071001；2.国防科技大学军事职业教育技术服务中心，湖南长沙 410000；3.中国软件与技术服务股份有限公司，北京 100081）

0 引言

大型企事业单位的信息化建设往往需要大规模地组织运用各类应用系统，在此过程中，既要开发新的业务系统和功能模块，又要对现存系统进行集成再造。Jinyoul等［1］指出基于组件的开发能促进企业集成。目前成熟的做法是通过实现应用支撑平台来完成整个信息生态的体系建设与系统集成［2-3］。应用支撑平台又可划分为基础支撑应用、系统集成应用、信息协同应用等，其中系统集成应用是实现信息全面集成的关键模块。系统集成应用需要从用户集成、界面集成、消息集成、数据集成、服务集成、工具集成等多个环节打通信息壁垒，其中用户集成是最为关键与首要的任务。

藏静［4］以用户数据集成为例阐述企业信息系统集成方法时，将人力资源数据库和业务系统用户同步到统一的用户库，通过保存业务系统用户的每一次信息变更进行用户数据同步，但存在较大的系统开销；杨金文［5］在讨论单点登录系统时，将统一的用户管理、统一的授权管理、统一的身份认证视为理想模型和解决方案，在小规模系统集成中效果较好，但在大规模异构系统集成中，特别是存在大量商业闭源业务系统的集成环境中，难以实现权限管理的完全一致和统一；徐步峰［6］基于Kerberos 实现认证模型，但为了避免单点故障、提高系统可用性，采用了冗余架构；雷传锐［7］针对CAS（Central Authentication Service，中心认证服务）认证方式，提出采用带权重的粗粒度、IP 禁止功能及登录次数阈值等模型和方法，提升了用户认证的安全性；祝庆绩［8］、张洁等［9］阐述了基于CAS 的认证中心实现方案；郑健［10］、陈国慧等［11］分别使用CAS 技术实现了校园认证中心和门户认证中心，但以上均把讨论重点放在CAS 技术本身，主要阐述了CAS 基本概念、交互认证原理和配置部署方法，而忽略了对大规模异构系统用户集成的实现逻辑分析与集成策略研究。

现有工作大多以实现单点登录为目标，局限于小规模应用场景的技术实现，而没有考虑到大规模异构系统集成环境下的系统开销大、权限管理难等问题，缺乏系统的集成逻辑分析与策略研究，也没有结合集成策略深入阐述CAS 的核心思想和框架使用逻辑。因此，本文从系统集成模块实现的角度，总结了用户集成的逻辑问题，分析了容易出现单点故障和用户权限错配的具体场景，提出改进策略和实现方法，并通过Apereo CAS 与Apache SHIRO 开源框架快速实现身份认证的集中式管理和角色权限的分布式管理策略。轻量级的原型系统验证了解决方案的可行性，该方案不仅适用于从零开始构建信息系统的用户集成模块，而且适用于对现有信息生态进行升级、改造、集成与调优。

1 用户集成逻辑问题与策略研究

企事业单位在大规模组织运用信息系统时，常常会遇到大规模用户集成的问题。为有效解决系统开销大、权限管理复杂等难题，消除单点冲突和权限错配，应首先分析相关逻辑问题，以便给出相应策略和实现方法。

1.1 符号约定

把内部信息生态中的所有应用记为集合M=｛A1，A2，…，An｝，其中An表示一个具体应用。把集合M 中的应用划分为若干个域，所有域的集合记为N=｛D1，D2，…，Dn｝。集合N 中的域一般分为3 种类型。不失一般性，把基于相同应用支撑平台和技术体系，使用相同机构用户及权限管理数据库，重构、在建及将建的应用划分到D1（如党建管理、外事管理等系统），即为第一类；把购买的某个商业套件下的应用划分到D2（如用友财务、人力、客户关系等应用），即为第二类；把某个独立的应用划分到D3（如开源邮件系统），即为第三类。以下所有策略都将以D1、D2、D3为具体实例进行说明。

1.2 用户数据存储域及用户管理实现域

将新建或大量重构的系统划分到D1，原则上使用相同的综合管理数据库和应用支撑平台进行用户集中存储与权限管理。对于域D2和D3，各自进行独立的用户数据存储与用户权限管理［5］。

1.3 域之间用户访问控制与认证授权问题

假设用户U 既是D1中的用户，又是D2中的用户，如果用户U 已通过中心认证登录了D1或D2中的任意一个应用Ak，则可直接访问D1和D2中的其它应用，而无需再次认证。假设用户U 是D1中的用户，而不是D2中的用户，其通过认证中心登录了D1中的应用An，此时要访问D2中的应用Am。Am检测到用户U 已通过认证并从认证中心获取到了用户信息，但Am通过查询本地独立的用户数据，发现用户U 不是本地用户，则跳转到Am应用的本地认证入口，提示用户进行认证。

1.4 不同域用户进行绑定与映射的身份标识

首先分析通过用户名作为标识进行映射会产生的逻辑错误。假设用户U 通过认证中心登录了D1中的应用An，正要访问D2中的应用Am。Am检测到用户U 已通过认证，并从认证中心获取了用户名name1，此时可能出现3 种逻辑错误：

（1）如果用户U 是D2的用户，但在D2中的用户名为name2，将造成用户U 无法正常访问Am。

（2）如果用户U 不是D2的用户，但恰好用户V 以name1在D2中注册过，将造成用户U 可非法获取用户V 在Am中的权限，从而访问到用户V 在Am中的操作视图，导致登录故障。

（3）如果用户U 在Am中的用户名为name2，用户V 在Am中的用户名为name1，此时表面上实现了认证授权，但会造成用户U 无法访问自己在Am中的操作视图，却可非法访问用户V 在Am中的操作视图，导致用户操作权限错配。

综上，应采用如下集成策略：创建新的中心认证数据库，用户以唯一标识（如电子邮箱地址）作为认证中心的身份标识，并用该标识作为中心认证数据库中的用户数据和各域用户数据的映射字段。例如：用户U 在D1中的用户名为name1，在D2中的用户名为name2，但在D1和D2中均留有唯一的name@163.com 电子邮箱地址，则通过绑定邮箱、用户名映射的方式在D1与D2之间正确地识别用户进行认证和授权，从而实现自由切换。

此外，之所以要创建新的认证中心数据库，是因为如果认证中心要针对不同应用和数据源进行认证与交互，不仅会造成逻辑错误，而且会增加集成开发的工作量和复杂性，甚至降低系统性能。

1.5 用户数据绑定与同步以及各域认证入口访问控制

（1）用户同步。各域的用户范围显然是不同的，将中心认证数据库同步到各域数据库不符合逻辑，增加了大量无效且冗余的用户数据拷贝。因此，解决策略是将各域中用户数据的少量关键信息同步到中心认证数据库。

（2）注册同步。各域对用户信息的内容要求不一，但至少要有中心认证数据库所要求的用户名、密码、邮箱地址3 项内容。在各域中，如果有新用户创建、身份标识（如电子邮箱地址）字段的增加或修改信息，则需要触发事件，把用户信息同步到中心认证数据库。如果用户U 是D1中的用户，在通过认证中心验证的前提下又在D2中注册时，应从认证中心自动获取D1中的身份标识作为注册字段。

（3）用户绑定。用户U 把在各域中的身份标识（如电子邮箱地址）修改成自己常用的唯一身份标识，即实现了同一个人在各域不同账号的绑定映射。

（4）认证入口。保留各域原有的登录与认证入口，当用户访问受限资源时，首先跳转到认证中心。如果未认证，则重新跳转到认证中心登录界面；如果认证中心已验证通过，则进入各域内部。此时如果不是各域的有效用户或不满足该域的访问权限，则跳转到各域原有认证页面或权限不满足提示页面。

不同应用间用户数据存储及交互策略如图1所示。

Fig.1 User data storage and interaction strategies of different application图1 不同应用间用户数据存储及交互策略

2 中心认证Apereo CAS实现

CAS 是用于实现Web 中心认证，使得单个用户只提供一次凭证即可访问多个应用的协议［7，12］。Apereo CAS 软件由CAS服务器和CAS 客户端［8，12］构成，可支持CAS、SAML、OpenID、OAuth 等多种协议［10，12］。

2.1 CAS协议核心思想及概念

CAS 的核心思想是应用程序的用户登录及身份认证交给CAS 服务器完成，用户身份认证成功后，其相应角色和权限则可交给CAS 服务器进行二次开发集成，也可交给CAS 客户端自己处理［12］。按照上文提出的集成策略，每个域为一个CAS 客户端，各域的用户操作权限交给各域处理，即身份认证的集中式管理和角色权限的分布式管理。CAS包括以下基本概念［7，12］：

（1）ST（Service Ticket）：代表访问许可唯一不可伪造的服务标识码，用户认证通过后，ST 由CAS 服务器发出，通过Http GET 请求的URL 参数传输，且只对当前用户有效。

（2）TGC（Ticket-Granting Cookie）：存放用于查询登录票据（凭证）TGT 的ID 信息的cookie，是CAS 服务器用来明确用户身份的凭证，也是CAS 服务器与客户端通信交换的载体，只能采用Https安全方式传输。

（3）TGT（Ticket Grangting Ticket）：存储在TGC 中，代表用户的一次会话，也是用户证明自己在CAS 服务器登录过的凭证。

2.2 CAS协议基本原理

当浏览器发出GET 请求要访问应用An时，An（CAS 客户端）拦截请求，把请求地址记录下来暂存，重定向请求到CAS 服务器的登录地址，并将An中CAS 客户端程序的接口地址一并发给CAS服务器。

假设是首次访问，则跳转到认证中心登录页，此时用户填写身份信息（如用户名）和凭证（如密码）并提交。若认证成功，则生成TGT 缓存在CAS 服务器，将TGC（TGT 的ID 信息）写入到客户端浏览器，签发ST，以ST 作为URL 参数重定向到CAS 客户端的接口地址。CAS 客户端收到携带ST 的请求后，将ST 转到CAS 服务器进行验证。ST 与TGT 若能匹配成功，则用户通过身份验证，CAS 服务器将用户信息回传给CAS 客户端，由CAS 客户端与用户建立会话，返回受保护的信息资源，并以网页形式呈现给用户。

当浏览器访问应用Am时，Am将请求跳转到CAS 服务器，CAS 服务器检查TGC（cookie），发现已经通过验证，则签发ST 发送给Am的CAS 客户端。Am的客户端收到携带ST 的请求后，转交CAS 服务器进行验证。验证通过后，CAS 服务器将用户信息回传给Am的CAS 客户端，由Am的CAS 客户端与用户建立会话，以网页形式呈现被保护的信息资源给用户。CAS 协议工作原理时序图如图2所示［11-13］。

2.3 CAS服务器搭建

（1）首先创建中心认证数据库，并将域用户数据同步至中心认证数据库ca_db。其中，必有字段为uid、username、password、email。email 为CAS 服务器和CAS 客户端用户数据的映射字段，一个用户可在多个应用中注册账号，同步到ca_db 后，则有了多条记录。登录名与密码可以不同，如果已经绑定，邮箱地址相同，只要使用邮箱和任意已有账号的密码，均能通过CAS实现身份认证。

（2）在maven 中加入cas-server-support-jdbc-drivers 和mysql-connector-java 支持包，编译一份CAS 服务器执行程序，以便采用读数据库比对密码的方式进行验证［10-12］。

Fig.2 CAS protocol interaction sequence diagram图2 CAS协议交互时序图

（3）用JDK 生成密钥库、证书文件并导入到JDK，修改tomcat的server配置文件，把密钥加入密钥库［9-10，12］。

（4）修改CAS 服务器配置，设置为JDBC 认证方式。CAS 可针对多个CAS 客户端的加密方式设置多种常用的加密校验方式，只要任意一种加密方式匹配成功即能通过验证。更为复杂的情况则需进行二次开发，以下为CAS 的JDBC 认证配置方法［11-12］：

3 CAS客户端的Apache SHIRO 实现

Apache SHIRO 可简单、快速地实现用户认证、加密、授权、会话、缓存及Web 集成等功能，用户、角色及权限数据的维护由使用者自定义并扩展实现，然后注入接口。域D1的应用支撑平台原型系统基于SHIRO 权限管理框架，通过集成CAS 实现具体应用的中心认证功能，使之变成CAS 客户端，而不是由CAS 集成SHIRIO 功能，直接管理用户授权及会话。在工程实践中，两者要加以区别［12，14］。

3.1 SHIRO核心概念

（1）Authentication：认证。

（2）Authorization：授权。

（3）Realm：从各类数据源获取用户、角色、权限数据，通过自定义机制实现认证、鉴权及授权，又称之为域。多个Realm 通过设置策略实现相关功能。

（4）Principals：身份标识，具有唯一性，如工号、邮箱地址等。

（5）Credentials：凭证，主体在证明自己身份时提供的凭证，如密码、票据等。

（6）Token：令牌，principals 与credentials 组合起来，构成身份验证的基本且完整的要素（如UsernamePasswordToken）［14］。

3.2 SHIRO集成CAS方法步骤

（1）在新建或大量重构的应用中增加cas-client-core和shiro-cas 依赖（具体实现时，好的架构通常是在应用支撑平台的系统集成应用中加入依赖），并在web.xml 中加入CAS客户端过滤器。

（2）修改SHIRO 配置文件，配置Filter 和Realm，包括自定义权限过滤器、安全认证过滤器和认证器域，即shiro-Filter、casFilter、casRealm，关键配置如下［14］：

图3 为运用本文所述方法快速开发的具有用户集成功能的应用支撑基础平台原型系统，其实现了CAS 客户端基本功能，能与CAS交互进行身份认证。

在原型系统中，CAS 服务器认证入口、应用支撑平台（CAS 客户端）认证入口以及CAS 客户端跳转至CAS 中心的网址分别如下：

（3）参考shiro-cas 包中CasRealm 类的源码，继承Cas-Realm、自定义认证类并重写回调函数。

Fig.3 Prototype system of application support platform including user integration module图3 具有用户集成功能的应用支撑原型系统

4 结语

在大规模信息系统的用户集成过程中，应把业务逻辑的分析和集成策略研究放在首要位置，以便解决逻辑冲突，避免单点故障和用户权限错配。基于开源安全框架Apereo CAS 和Apache SHIRO 实现集成策略具有开发快速、安全稳定及轻量级等优点。未来的工作重点将放在原型系统的改进和实际工程应用上，通过实施大规模异构系统的用户集成，大量收集与分析系统集成应用的状态数据，以进一步检验与完善集成策略的完整性、正确性、安全性及运行效率。