摘 要：摘要：高等学校数字化校园已经成为高校行政办公、教学、科研的重要支撑手段，并且渗透到日常学习、生活中来。近年来，各大高校纷纷开展各种应用系统建设，但各应用系统由于建设时间、厂家选型、技术路线不同，亟需在数字化校园应用之上建设完善公共EAI（企业级应用集成）平台，以将各应用系统进行集成，实现数据、认证、访问的统一。本文结合企业在高校的实践，结合 IBM公司的Tivoli 系列产品，提出一种通用的统一身份认证设计与建设方案，并最终在具体项目上予以成功实施。相关设计与管理思路可供各大高校在统一身份认证尤其是IBM Tivoli选型、建设和运行维护时参考。
关键词：关键词：数字化校园；EAI企业级应用集成；统一身份认证；Tivoli
中图分类号：TP39 文献标识码：A 文章编号：
1. 现状与需求
目前很多学校存在的应用系统均是针对各部门、各单位的具体工作来进行设计的，缺少统一的规划和全校一体化考虑，在系统认证登录方面存在多重身份和密码体系，口令保存均采用数据库，且并不是所有系统均加密报护用户口令。这种现状给管理、使用带来了极大的障碍。
统一身份认证系统提出的目的就是要解决不同的网络应用系统用户名和口令不统一的问题，期望提供统一的授权机制及一套方便、安全的口令认证方法，让用户只要一套用户名和口令就可以使用校园网络上他有权使用的所有应用系统。这需要在解决方案中考虑解决以下几方面的问题：
提供适合高校用户数据分散管理的用户数据集成；
提供适合高校用户尤其是教职工多重身份的实际情况的用户数据存储模式；
提供足够开放和完整的认证集成方式，以保证原有应用系统和学校后续应用系统能够实现和统一身份系统的集成，让用户获得完整的单点登录体验；
满足不同用户或系统的认证安全需求；
保证统一身份认证系统的高可靠性和性能。
2. 总体架构设计
结合高等学校的应用场景，规划设计的统一身份认证系统架构如下：
图1：高校统一身份认证系统架构设计
a) 认证对象层
认证对象层主要是指接入身份认证系统的各业务系统。
b) 接口层
认证接口服务为外部应用访问统一身份认证系统提供了高可用性和跨平台的接口和通道。通过认证接口可以获得用户身份认证、用户身份数据提取、单点登录等服务，同时可以获得认证服务负载均衡的能力。
c) 服务层
认证与授权服务提供了系统的核心基础服务，用于学校对师生用户的数字化身份的认证，创建并维护用户的单点登录会话。
目录服务与现有系统集成在一起，充当一个集中化的身份信息库，用于将用户的信息集中存储。
数据同步服务实现了外部权威数据源向统一身份认证系统同步身份数据的功能，并实现身份管理业务与学校核心业务的集成。
d) 管理控制层
管理控制台承担整个统一身份认证平台的身份数据管理、系统服务管理、系统运行管理工作，是整个平台的集中管理控制中心。管理控制层通过安装在各个服务器上的管理控制代理实现对各个组件的实时监视、远程控制、远程配置，并提供用户数据、口令、策略、权限等管理功能。
3. 身份目录结构策略
身份数据采用 LDAP 目录服务进行存储，目录服务就是按照树状信息组织模式，实现信息管理和服务接口的一种方法。在 LDAP 中存储类别被称为“容器（Container）”，由于我们在 LDAP 中存储的是人员信息，通常也称为“人员容器”。在人员容器下可存储子容器，也可同时存储子容器和身份数据。一般的经验方法是使容器的结构尽可能地保持简单，并且不危及将来的可扩展性。对于高校来说，建议按照如下策略划分：
图2：高校统一身份认证用户身份目录结构设计
4. 身份数据流程
身份认证平台被作为一个身份数据集中存储的平台，所有人员的身份数据都应该纳入平台的身份数据存储中。然而，由于这些身份数据都是存在于各个业务系统数据库中，并且由业务部门各自负责维护，所以身份数据的源头并不在身份认证系统，需要通过合理的数据同步方法将各个源头的身份数据同步到身份认证系统，以保证身份数据的权威性。该方案中我们选择IBM Tivoli相关功能套件予以实现统一身份认证，其相关功能组件结合高校实际拓扑结构如下：
图3：高校统一身份认证系统数据流程策略
（1）数字化校园中主要的人员基本信息，来源于人事系统、教务系统、研究生系统；
（2）人员基本信息，通过数据集成平台，流转入共享库的人员基本信息表中；
（3）通过TDI，从人员基本信息表中抽取身份数据，通过流水线写到TIM中；
（4）TIM保存人员数据，并根据身份数据中人员的类型根据不同策略生成若干账户；
（5）TIM生成的统一身份认证帐号将保存在TDS中，供TAM在身份认证中使用，并向门户提供所需要的身份信息；
（6）可以使用文件将人员基本信息数据以EXCEL文件方式直接导入TIM中，并通过相应的策略生成帐号；
（7）在TIM的管理界面中，可以直接对临时人员、管理员帐号等特殊用途帐号进行手工管理。
5. 应用集成方案
a) 基于认证接口
基于认证接口是传统的认证集成方式，原理是采用ICE作为通讯中间件，采用API开发一个认证代理。同时对目标应用进行改造，将其用户认证部分改造为通过访问认证接口实现，需要在目标应用中引入认证接口的JAR包并修改代码。在运行时，目标应用调用认证接口访问认证服务，判断用户请求是否合法，并获取用户身份信息。
b) Http BA Header
基于Http BA Header的认证方式原理是通过WebSeal的方向代理功能对目标应用资源进行保护，用户对目标应用的访问均需要通过WebSeal。WebSeal根据安全策略对访问请求进行判断，中止不符合安全策略的访问要求。WebSeal在请求的Http BA Header中加入含有用户身份信息的参数，目标应用通过解析Http BA Header获得所需要的用户基本信息。
c) IBM LTPA协议
IBM LTPA协议为IBM自有的身份认证集成和SSO协议，原理是基于Cookie只是在加密方式和通讯方面有区别。通过使用IBM LTPA协议，可以方便与IBM的产品进行集成，如WebSphere的应用、Domino应用等。
对于应用，可以实现通过JAAS将用户身份认证交给应用服务器。基于这种方式，只要将实现JAAS的应用部署到IBM WebSphere应用服务器上，就可以通过将IBM WebSphere应用服务器集成到TAM，从而实现将这些部署在WebSphere上的应用的身份认证功能都集成到TAM中。
d) F
orm SSO
Form SSO是通过识别目标URL的HTML页面中用于输入登录信息的Form，将存储在AM中的用户身份信息和口令代填到form中，从而实现单点登录的方式。通常也称为伪SSO或者用户映射。这种方式能够集成无法修改代码进行改造的应用。
为便于快速集成各业务系统，下面将四种集成方式进行比较：
表2：统一身份认证应用集成方案对比
6. 建设成果
该项目的Tivoli环境由TDS，TAM，TDI三个功能组件组成。TDS作为基础数据源，存储结构化数据。TAM负责身份验证及安全访问控制。TDI充当各数据源之间的桥梁，抽取、转换，同步数据信息。最终系统安装部署的拓扑结构如下：
图4：高校统一身份认证系统部署拓扑架构
TDS部分由实时复制的两个LDAP实例组成。LDAP对外暴露的访问方式为HACMP产生的虚拟地址，实现了高可用性。
TAM部分主要由策略服务器和Webseal访问代理组成，策略服务器实例运行在HACMP之上，实现高可用性及故障切换。Webseal由相同的两个实例组成集群，经由F5负载均衡后提供对外访问方式，实现了容灾。
TDI两个实例为热备状态，且物理分隔。当一个实例出现故障时，TDI服务自动failover到另外的服务器上，实现高可用性。
该项目目前已经集成了校内30余个业务系统，解决了统一身份认证系统建成前学校存在的如下问题：
用户需要记忆多套帐号/口令，在使用多个业务系统时操作烦琐，极不方便的情况；
业务系统管理分散，形成了帐号信息孤岛，因重复管理而付出高昂的管理成本；
各个业务系统采用不同的认证技术和规范，认证系统之间数据不统一；
帐号存在多人使用问题，发生安全事故后难于确定帐号的实际使用者，难于对帐号的扩散范围进行控制，容易造成安全漏洞；
因学生毕业、教职工离职、IT服务商测试等原因出现的“幽灵帐号”问题无法得到解决，存在严重安全隐患；
没有集中的帐号管理系统、规则，无法按流程自动处理对帐号的生命周期管理；
不能统一对帐号设置口令安全策略，无法实现对口令进行统一的强度控制和定期自动更改等功能；
缺乏合理的审计手段，出现问题难以审计，因无据可查导致责任难以定位；
没有统一的授权管理功能，因权限控制不严造成信息泄漏。
7. 结语
本文是在笔者及其项目团队，在充分研究统一身份认证系统的普遍需求，结合IBM Tivoli 系列产品特点，参考类似业界产品，如Oracle AM、DS等，进行独立测试、验证，并在广东外语外贸大学并成功实施的。这个项目的最终实现在高等教育行业属于国内先例。
借此一并感谢广东外语外贸大学现代教育技术中心的相关领导和老师，感谢他们的积极配合和协调。也更感谢江苏金智教育的项目组成员，正是他们的日夜攻坚、大胆尝试、积极探索，最终使得项目成功上线。
参考文献：
IBM Tivoli产品线信息中心
