正方接口规范集成规范
1 总则
1.1 目的
为了规范学院数字化校园系统的集成,规范各业务系统与数据中心之间、业
务系统与业务系统之间的数据交换及服务集成,特指定本规范。
1.2 范围
学院各业务系统针对数字化校园基础平台的集成,各业务系统与数据中心之
间、各应用系统之间的数据交换应遵循本规范。
确定要进行系统集成的各现有应用系统应遵照本规范进行改造,在建及今后
建设的应用系统,不论是否需要进行系统集成,都要遵循本规范。
1.3 应用系统集成的层次
应用系统集成分三个层次,即服务集成、认证集成和数据集成。
服务集成,即通过统一信息门户平台的集成功能集成到门户网站;认证集成,
即通过统一身份认证平台进行的单点登录集成;数据集成,即通过数据中心平台
的数据整合工具将业务系统的数据采集到数据中心的共享数据库此为抽取,通过
数据中心平台的数据订阅工具将数据中心共享数据库的数据下发到业务系统此
为订阅。
应根据业务需要和应用系统的特点确定进行哪几个层次的集成。
1.4 规范的生效
本规范自发布之日起生效。
1.5 规范的维护
本规范应根据业务发展的需要定期更新,本规范的版本更新时应保证向下兼
容。
2 服务集成规范
2.1 服务集成的方式
服务集成包括以下方式:
URL 功能服务
WEB 剪辑
Iframe 集成
RSS 集成
WebService 集成
数字化校园基础平台支持上述集成方式,提供进行上述集成的配置工具。
2.2 URL 功能服务
URL 功能服务是把各应用系统提供的功能,以登记访问 URL 的方式进行服
务注册,当用户访问该功能时,通过 URL 直接调用应用系统的功能。
需要提供用户直接调用某项功能的应用系统,应提供通过 URL 传入参数的
方式直接调用某项功能。数字化校园基础平台需提供将这种调用方式注册配置成
服务的工具。
2.3 WEB 剪辑
WEB 剪辑是指从应用服务器可以访问到的页面进行区域裁剪,裁剪后的内
容作为提供的服务进行注册调用。数字化校园基础平台需提供将这种调用方式注
册配置成服务的工具。
2.4 Iframe 集成
数字化校园基础平台需提供将应用系统的某些页面整体嵌入到信息门户页
面,并注册成服务的功能和工具。
2.5 RSS 集成
数字化校园基础平台将符合 RSS 规范的网站内容封装成服务的形式供最终
用户展示。业务系统只需要提供支持 RSS 规范的服务内容即可。
2.6 WebService 集成
业务系统提供标准的 WebService 服务,数字化基础平台通过调用这 些
WebService 获取相应数据,并通过表单或列表的方式进行展示的方式, 叫
WebService 集成。需要进行这种方式集成的业务系统应提供这些 WebService 服
务及调用参数。
业务系统提供 WebService 服务地址,命名空间,调用方法,参数组(包含
参数类型)。
返回值请按 XML 格式,并提供数据字典。
数字化校园基础平台提供工具配置针对这些 WebService 服务的调用,及所
获取数据展示方式。
3 认证集成规范
3.1 认证集成的模式
认证集成可以采用以下四种模式:
A.URL 单点漫游模式
B.ZFCA 认证模式
C.WebService 认证
D.伪登录模式
数字化校园基础平台全部支持以上四种模式,应用系统应支持 URL 单点漫
游模式、ZFCA 认证模式、WebService 认证中的至少一种。已经不能改造的在本
规范发布之前建成的应用系统进行认证集成时可以采用伪登录模式进行认证集
成,此认证方式为安全级别最低的集成方式,一般不建议采用。
3.2 URL 单点漫游模式认证集成
3.2.1 认证过程
用户通过统一信息门户进入业务系统时,统一信息门户通过 URL 向业务系
统传递认证需要的参数,业务系统通过校验这些参数确定认证是否通过。
3.2.2 传递的参数
用户通过统一信息门户访问业务系统时,统一信息门户须向业务系统传递如
下六个参数:
1) userName:业务系统中的用户帐号;
2) strSysDatetime:时间戳,自 1970 年 1 月 1 日午夜起至现在的时间差,
精度为秒,标准格式为 yyyy-mm-ddhh24:mi:ss;
3) verify:校验码,由 userName、strSysDatetime、jsName 及公钥通过 MD5
加密方式加密产生;
4) jsName:业务系统中的用户角色名;
5) url:访问业务系统某项功能时的访问地址;
6) gnmkdm:被访问的业务系统模块在业务系统中的模块代码。
3.2.3 参数的加密
校验码 verify 由 userName、strSysDatetime、jsName 及公钥通过 MD5 加密
方式加密产生,加密算法由数字化校园基础平台的公共包(支持 Java、.Net 等)
提供,加密所需的公钥通过配置保存在基础平台和业务系统都能读取的公共数据
表中,一般情况下,这个公共数据表保存在基础平台的数据中心数据库中,特殊
情况下也可以保存在业务系统建立的供外部系统读取的数据库中。
3.2.4 参数的传递
参数通过 URL 的方式由统一信息门户传递给业务系统,格式如下:
url?verify=校验码&userName=用户名&strSysDatetime=时间戳&jsName=角
色名&gnmkdm=模块代码
如:
http://192.168.1.101/index.asp?verify=0188F3F3BD26A72BD6D61C244DA38
EE8&userName=20089006072&strSysDatetime=2009-07-0310:02:08&jsName=teac
her&gnmkdm=1001
3.2.5 认证过程和结果判断
业务系统获取各个参数后,首先比较业务系统服务器时间同传递过来的
strSysDatetime 是否在允许的时间差范围内(注意双方服务器时间需保持标准时
间),若在时间差范围内,则需将 userName、strSysDatetime、jsName 及公钥通
过加密算法提供的公共包进行加密后返回的结果同 verify 进行比较,若一致,则
可以正常登录。否则不允许登录。
3.2.6 参数的配置和保存
数字化校园基础平台应提供技术手段配置和保存“平台用户”和“业务系统
用户”对照表、“平台角色”和“业务系统角色”对照表、业务系统访问地址、
业务系统可访问模块的访问地址、业务系统模块代码表。
3.3 ZFCA 认证模式认证集成
3.3.1 ZFCA 认证服务平台
ZFCA 认证服务平台包含在数字化校园基础平台的统一身份认证平台中,用
于实现用户身份认证。
3.3.2 认证过程
用户通过统一信息门户登录,首先要通过 ZFCA 认证服务的身份验证,ZFCA
认证服务器向用户浏览器返回一个用户凭证,以 cookie 的方式保存到用户浏览
器端。同时,在 ZFCA 服务器中产生一个 Session 对象,保存用户身份等信息。
用户通过统一信息门户访问业务系统时,如果该业务系统是通过 ZFCA 认证
模 式 进 行 统 一 身 份 认 证 的 , 则 存 在 与 业 务 系 统 中 的 用 户 身 份 过 滤 器
(ZFSSOFileter)会与 ZFCA 服务器通讯,尝试取得包含用户身份信息的 Session
对象,如果能够取得,则说明用户身份合法。如果取不到,则说明用户还没有通
过身份认证或者 Session 已过期,需要用户重新登录。
3.3.3 业务系统实现 ZFCA 认证
为了实现上述认证过程,业务系统需要进行一定的改造,改造方式如下:
3.3.3.1 基于 J2EE 的业务系统
1) 将 统 一 身 份 认 证 平 台 提 供 的 公 共 开 发 包 中 的 zfcaclient.jar 和
zfcasingleout.jar 复制到应用程序 lib 目录下;
2) 修 改 公 共 开 发 包 提 供 的 ZFSSOFilter.java , 修 改 方 式 根 据
ZFSSOFilter.java 中的说明,并将 ZFSSOFilter.java 编译到业务系
统的执行代码中。
3) 将以下内容加入到业务系统的 web.xml 中:
org.jasig.cas.client.session.SingleSignOutHttpSessionListener
CAS Single Sign Out Filter
com.zfsoft.util.filter.SingleSignOutFilter
CAS Single Sign Out Filter
*.do
ZFSSO Filter
com.zfsoft.util.filter.ZFSSOFilter
notCheckURLList
ZFSSO Filter
*.do
3.3.3.2 基于.Net 的业务系统
1) 将 统 一 身 份 认 证 平 台 提 供 的 公 共 开 发 包 中 的 login_cas.aspx 、
login_cas.aspx.resx 和 login_cas.aspx.vb 复制到应用程序 lib 目录下;
2) 修改 login_cas.aspx.vb,修改方式根据 login_cas.aspx.vb 中的说明,主
要修改成功登录后跳转的 URL,并将其编译到业务系统的执行代码中。
3) 将以下内容加入到业务系统的 web.config 中:
以上内容中,ZFCA 表示 ZFCA 服务器的地址,CA_PORT 表示端口号。
3.4 WebService 认证集成
3.4.1 对基础平台的要求
统一身份认证平台提供实现下述认证过程所需要的 WebService 调用。
3.4.2 认证过程
1) 用户登录统一信息门户时,统一身份认证平台在用户身份认证校验通
过后会产生 SSO_ID 并返回。
2) 用户通过统一信息门户访问业务系统,在统一信息门户传递给业务系
统的 URL 中,将包含 SSO_ID,以 QueryString 的方式传递。
3) 业务系统的入口页面从 QueryString 中获取 SSO_ID 并调用统一身份认
证平台的 getSSOUser 方法(WebServices 方式)获得用户帐号等其他
信息。
4) 业务系统根据用户帐号加载权限并完成后续工作。
3.4.3 调用方式
统一身份认证平台公布 WebService 服务地址(具体部署确定),命名空间(根
据学校实际情况变化),调用方法(getSSOUser),参数组(ssoCenter,ssoId)。
调用格式为:getSSOUser(ssoCenter,ssoId),其中 ssoCenter 为 WebService 服
务提供的地址,ssoId 为 QueryString 传递过来的 SSO_ID
3.4.4 业务系统的改造
业务系统的入口页面加入从 QueryString 中获取 SSO_ID 并调用统一身份认
证平台的 getSSOUser 方法(WebServices 方式)获得用户帐号,并根据该用户帐
号完成权限加载等工作的代码。
3.5 伪登录模式认证集成
3.5.1 认证方式
用户通过统一信息门户平台访问业务系统,统一信息门户平台模拟用户登录
业务系统的方式,直接将用户帐号和密码写到业务系统的登录页,并提交表单,
实现用户的登录。
3.5.2 适用场合
这种方式不影响业务系统原有的运行方式,不需要业务系统进行任何改造。
但采用这种方式进行认证集成的业务系统原有登录界面不能有校验码输入;业务
系统用户增加时,不能自动同时增加平台用户,反之亦然;采用这种方式集成,
要求用户的业务系统密码与平台密码相同。
由于有上述不利因素,这种认证方式只适用于无法进行改造的原有业务系
统,且这些系统登录时不需要输入校验码。
4 数据集成规范
4.1 数据交换的方式
数据交换方式可以使用如下三种方式:
数据抽取和订阅