西北农林科技大学信息资源系统技术规范.doc

西北农林科技大学信息资源系统技术规范

20
2020年5月29日
文档仅供参考
西北农林科技大学信息资源系统技术规范
为了进一步规范我校数字校园建设,保障信息资源共享和信息资源系统集成,根据<西北农林科技大学数字校园建设规划>,特制订以下技术规范:
1、 适用范围:各职能部门改建、新建的信息管理系统、信息资源系统等;
2、 系统规范:信息资源系统的服务端(Web服务器、应用服务器和数据库服务器)能够在Unix、Linux操作系统上运行,支持Oracle数据库;
3、 架构规范:信息资源系统应采用B/S结构的三层架构,即Web服务器、应用服务器和数据库服务器,以方便用户使用;
4、 开发技术规范:应采用JavaEE(J2EE)标准、组件技术及在数据交换上对XML的支持;
5、 数据交换规范:当业务系统需要与数字校园平台的公共数据库进行数据交换时,要按照学校制定的数据同步方案执行(附1);
6、 信息编码规范:信息资源系统所用编码应符合<教育管理信息化标准>(第一部分:学校管理信息标准)( .9),教育部远程教育标准(DLTS)和西北农林科技大学自编编码规范;
7、 统一身份认证集成规范:B/S架构的业务系统与数字校园进行SSO集成时,要按照学校制定的SSO集成方案执行(附2),建议尽量采用集成方案一;
8、 扩展性规范信息资源系统须具有良好的扩展性。业务系统建设的长期性和内容的广泛性决定了系统在构建和使用过程中,必然面临着各类扩展性需求,例如业务规模的扩展、业务类型的扩展等。因此要求模块间应相对独立,接口清晰,内部的业务流程升级和改造与其它模块无关,并为将来学校二次开发提供开发API等;
9、 本规范未尽事宜联系校网络信息中心;本规范最终解释权归校网络信息中心。

二○○九年四月二十四日
附1:
数据同步方案
第一章 数据同步流程
数据同步是指第三方业务系统与数字校园公共平台之间进行的周期性数据交互,包括数据从业务系统到公共平台的同步以及数据从公共平台到业务系统的同步两个流程。

一、 从业务系统到数字校园平台的同步

为了实现数据的准确性同步,需要第三方开发商在其业务系统的数据库中建立中间表,该中间表是在数据同步过程中数字化校园平台同步工具的操作表,如图1－1所示。故需第三方开发商对该表赋予一定的操作权限。

图1－1
该中间表的表结构除了具有原业务数据表中需同步的字段(字段名、类型和长度必须相同)外,还须具有标识字段。该字段是用来存储每条记录的增加、删除与修改等操作方式信息。对于需同步的原数据表,可在该表上建立一个触发器,在该表中数据发生变化时,触发器应该及时地将发生变化的数据插入到中间表中,并把操作方式记录到相应的标识字段中,以供数字化校园平台读取或操作。
数字化校园平台也会在其数据库中建立相应的中间表,其表结构与第三方业务系统提供的中间表表结构相同,并周期性的将业务系统中间表的数据同步到该中间表中。经过数据清洗将数据及时的更新公共数据库中的目标表中,进而实现了第三方业务系统中的数据可持续地与数字化校园平台之间的同步。

二、 从数字校园平台到业务系统的同步

为了配合第三方业务系统从数字化校园平台同步相关数据的需求,数字化校园平台能够根据其需求为其提供相关数据字段内容的中间表,并能够在该表中建立某些标识字段。该中间表作为一个第三方业务系统与数字化校园平台数据同步的接口,如图1－2所示。

图1－2
数字化校园平台会及时地将数据的更新情况反映到该表中。同时能够为第三方开发商提供对该中间表进行操作的一定权限,以供其实现从平台公共数据表中同步数据的需求。
第二章 需要第三方厂商做的工作
三、 从业务系统到数字校园平台
在数据从第三方业务系统到数字化校园平台的同步过程中,数字化校园平台需要第三方开发商在其业务系统的数据库中建立一张中间表,并给予对该表具有一定的操作权限。在该表中数据发生变化时,触发器应该及时地将发生变化的数据插入到中间表中,并把操作方式记录到相应的标识字段中。如图2－1虚线部分所示。

图2－1

四、 从数字校园平台到业务系统
在数据从数字化校园平台到第三方业务系统同步的过程中,数字化校园平台只会为第三方业务系统提供相应的中间表及一定的对表操作权限作为接口供其操作,如图2－2虚线部分所示。

图2－2
第三章 数据同步数字校园平台做的工作
一、 从业务系统到数字校园平台
在数据从第三方业务系统到数字化校园平台的同步过程中,数字化校园平台会从第三方业务系统提供的中间表中读取数据到平台下的中间表中,并对其进行数据清洗,将清洗后的结果数据导入到公共数据库中,如图3－1虚线部分所示。
图3－1
二、 从数字校园平台到业务系统
在数据从数字化校园平台到第三方业务系统同步的过程中,数字化校园平台会为第三方业务系统提供相应的中间表作为接口供其操作,并把数据的更新情况及时的反映到中间表中以实现数据同步,如图3－2虚线部分所示。
附2:
数字校园平台统一身份认证(SSO)解决方案
方案1、采用信息平台提供的统一身份认证系统实现SSO
集成前提:
各业务系统使用全校统一的教职工号或学号来做为系统的登录账号。
实现:
一、CAS客户端的主要作用
1.以filter的形式,对后方应用系统资源进行过滤保护。
2.获得CAS Server颁发的ServiceTicket,并凭此ST从CAS Server上取得登录用户信息。
3.为第三方应用提供开发接口,使得受保护的应用能够经过CAS认证进行正确的登录。
二、第三方主要完成的工作
1. 第三方系统开发商需要完成以下两个主要工作:
1)在自己的应用中配置CAS客户端。
2)取消此应用原先的认证登陆程序(不是必须的),改为根据CAS认证信息处理登陆。
2. 在应用中配置CAS客户端
需要以下步骤:
a)首先需要东软公司封装的CAS Client JAR包给第三方系统开发商。
b)在应用的web.xml中加入 CAS Filter相关的filter配置。配置信息如下:

其中,filter-class属性需要指定项目中使用的CAS过滤器类。上面的配置中指定的是默认的CAS过滤器类。第三方系统能够根据处理登陆的操作来扩展此类并覆盖相关方法。如某应用在这里配置了自己扩展的类:

而url-pattern属性中需要写明受保护资源的URI。一般情况下都是”/*”,它表示此应用中的所有资源均需要受到保护。
c)配置casFilterConfig.xml。这个文件需要放在对方应用的/WEB-INF/classes下。

指的是CAS Server的登陆URL;
指的是CAS Server的验证URL(需要这个配置来告诉CAS Client获取Service Ticket后发送给这个地址进行验证从而取得用户信息)。对于当前公司的CAS Server版原来说这两项是相同的。
指的是当前要集成的第三方应用的服务器和端口号,服务器能够是机器名、域名和ip等,最好使用域名。端口不指定的话默认是80。
下的指定了不需要CAS Filter进行过滤的资源。
CAS 提供了一个CASFilterRequestWrapper 类,该类继承自HttpServletRequestWrapper,主要是重写了 getRemoteUser() 和getUserPrincipal ()方法,只要配置的时候为其设置为 true,就能够经过其getRemoteUser() 方法来获取登录用户名:
CASFilterRequestWrapper  reqWrapper=new CASFilterRequestWrapper(request);
out.println("The logon user:" + reqWrapper.getRemoteUser());
还能够经过其getUserPrincipal()能够得到包含登录用户名的Principal对象:
CASFilterRequestWrapper  reqWrapper=new CASFilterRequestWrapper(request);
out.println("The logon user:" + reqWrapper. getUserPrincipal ().getName());
3. 改为根据CAS认证信息处理登陆
第三方j2ee应用可能都会有特殊的判断用户是否已经登录的逻辑以及特殊的存储在Session中的用户登录信息。因此要完成第二个步骤,第三方j2ee应用能够经过扩展CAS Client端提供的com.neusoft.education.tp.sso.client.filter.DefaultCASFilter这个类,并覆盖其中的如下四个方法来实现在过滤的过程中处理业务系统登陆操作,而且在web.xml中的< filter >属性中写入自己扩展类的类名
a)isNeedCASLoginOrValidate

这个方法判断请求的用户是否需要经过CAS登陆和验证。返回true则需要;返回false则不需要并直接进入业务系统处理登陆后的操作。此方法需要进行如下判断:判断当前获取的CASReceipt对象是否有效(代表是否是已经经过CAS Server认证的用户),而且对不需要filter过滤的资源进行特殊处理(在casFilterConfig.xml中下的中记录的资源会自动放行)。注意:第三方系统覆盖此方法进行特殊处理时必须要调用此方法进行默认的处理。如,某应用中,覆盖此方法的例子如下:

b)isNeedRedirectToCAS

当isNeedCASLoginOrValidate方法返回true(代表用户需要访问受CAS Client保护的资源但用户尚未经过CAS Server认证)的时候,正常情况下会直接转向CAS Server的登陆地址。但如果第三方系统需要在CAS Client将用户请求重定向到CAS Server进行登陆操作之前处理一些特殊逻辑判断或处理的话,则在此方法中完成其操作。返回true则转向,false则不转向。DefaultCASFilter中的这个方法直接返回true,转向CAS Server进行登录验证。
c)isNeedValidate

当CAS Server对登陆用户完成认证后,会生成Service Ticket放在URL中返回给客户端浏览器重新定向到CAS Client端。CAS Client端得到ST后,正常情况下会拿着这个ST去CAS Server端进行确认以得到用户的身份信息。但如果第三方系统需要在CAS Client拿着ST去CAS Server进行确认之前做一些特殊逻辑判断或处理的话,则需要在此方法中完成其逻辑处理。返回true,则去CAS Server端确认并得到用户身份;返回false,则不去确认,这样也就得不到用户的身份。DefaultCASFilter中的这个方法直接返回true,转向CAS Server进行确认。
d)userLoginAndValidated

如果用户已经经过了CAS Server的登陆验证,那么在这个方法中处理登陆验证成功后的操作,比如将需要用到的用户信息放入session等操作(第三方系统需将自己处理登陆验证后的逻辑写在这个类中)。特别注意:第三方系统在其覆盖方法中做处理之前一定要调用此方法进行默认处理:
super.userLoginAndValidated(request, response, receipt);
否则就会导致isNeedCASLoginOrValidate方法得到错误的结果。如report3.0中,此方法的覆盖例子如下:

完成以上工作后,经过CAS实现第三方系统的SSO集成基本也就完成了。

方案2、使用与第三方系统共享密钥方式实现SSO
这种方式实现SSO要双方的系统在共享密钥的设置(包括密钥的生成、认证过程中密钥的交换方式等)达成一致。具体方案如下:
Ø 前提条件:
1)平台用户账号和第三方业务系统账号如果不同,需要在公共数据库中建立对应关系。
Ø 实现条件:
1)平台服务器和第三方业务系统服务器的系统时间要保持一致。因为第三方业务系统需要经过我们传递的时间戳参数time_stamp来校验请求在时间上的合法性。
2) 如果使用静态密钥的话,需要双方系统开发商约定好共同使用的密钥KEY是什么(随意,最好复杂些但有规律)。如果使用动态密钥的话,那么第三方系统需给我们提供其生成动态密钥的系统接口供我们调用。
3)双方系统开发商约定传递给她们的参数有哪些,以及传递的方式是什么。
4)承建数字校园平台的东软公司和第三方业务系统开发商约定好需要校验的加密字符串en_string的组成规则。如:第三方业务系统用户名user_name+KEY+time_stamp。
5)约定好校验字符串的加密方式是MD5或其它加密方式