运用CAS模型实现数字校园统一认证*

鲁 学，汪丽华

（黄石职业技术学院，湖北 黄石435003）

一、问题的提出

不同等级和规模的学校，数字校园建设任务涵盖面虽有所不同，但大体目标是实现学校的数字化管理、数字化教学、数字化服务等等，实现方式是部署应用多种信息系统。事实上，中高等学校对应于不同的内部职能，多年来，逐步建立了多种信息系统，并且，这些系统来自不同的软件厂商，开发和运行平台各异，用户登录自成体系。虽然这些系统能够满足师生不同业务的应用需要，但用户要面对不同的登录地址和帐号，使用繁锁、帐号易忘，一定程度上削弱了使用热情。并且，这种格局也不符合数字校园一体化的性能要求。

另一方面，由某一家开发商推倒重建并应用的所有系统，形成统一平台的做法难以满足专业化要求，也不具有现实性和必要性。至于基于云架构，实现多院校公共的SaaS行业应用平台，在相当一段时间内，对多数学校还只能是一种难以实现的构想。那么，如何基于多系统并存的现状，实现学校师生用户的统一认证、单点登录（SSO）成为数字校园建设中的重要课题之一。

二、技术分析及CAS模型

目前广为应用的各类B/S系统，实现用户认证和登录的基本原理是：用户从浏览器输入用户名和密码后提交Web服务器，Web服务系统从数据库中比对后，确认用户角色及其拥有的权限，生成包含相应菜单的主页返回浏览器供用户操作，同时，以Session或其它后台技术暂存登录用户ID及其权限信息，这些信息可在服务器驻留一个有效期时间，以备系统的各功能子模块进行操作鉴权。但是，不同平台、不同系统，登录过程中的具体认证过程和驻留信息的参数和方式各异，并且，多被软件编译，除软件开发商外，他人不能更改登录认证代码，无法通过逐个修改的手段，实现数字校园多系统统一的登录认证。并且，一个运行稳定的系统也不主张随意修改。

CAS（Central Authentication Service）协议是由美国耶鲁大学2001年发起建立的一套跨平台SSO简单实效认证模型，具有足够的安全选择，被很多项目采用。CAS现有1.0、2.0、3.0三个版本：1.0版本奠定了基本的框架协议，2.0支持多层SSO能力，3.0增强了扩展能力，设计框架支持Sping。由于学校多系统之间极少存在相互嵌入认证，数字校园的认证体系采用CAS1.0即可满足需要。CAS1.0的认证模型如图1。

图1

虽然学校现有的各种Web应用系统，大多不支持CAS协议，或者说不具有CASClient。但要求软件开发商，按照学校制定的CAS协议，不需要对既有系统进行太多的代码改动，外加开发一个独立的CAS入口模块，就可实现对CAS模型体系的完全兼容，是一种现实可行的方案。

三、数字校园统一认证方法

图2 数字校园统一认证集成门户逻辑时序图

以上认证过程时序图中包含四类工作对象：PC浏览器是用户登录各类应用的终端；认证和集成门户是专门开发的具有CASServer功能的新站点，用以实现用户的登录认证、CAS票据ticket的生成、各应用系统的CAS入口链接集成、提供Service接口用于应用的统一认证；应用CAS模块相当于CASClient端，根据不同应用开发，是加挂于各应用的认证入口；数据库系统不属于CAS模型范畴，泛指存储系统，以便于时序的清晰描述。以上工作时序总体分四个阶段：

（1）门户认证阶段。用户从浏览器登录Web门户，门户系统从数据库中检索用户帐号，认证通过后，可将用户帐号与时间戳合成一动态序列值，或用MD5加密成字符串作为ticket，并将这个ticket值连同用户ID、登录时间存储到数据库的ticket表中；同时，触发数据库程序，按既定的登录生命周期时限，清理过期的ticket记录。

（2）生成门户主页阶段。门户系统生成学校各Web应用名称列表，列表可以是整个应用的入口（index），也可以是某一系统的单个应用模块。同时，分别建立各应用列表的CAS模块的入口链接，并携带两个参数，参数一为动态生成的且业已保存到数据库中的ticket字符串，参数二为Web应用模块对应的url。入口链接例如：〈a href=”http：//x.x.x.x/JWcas?ticket=987654321ffamp;service=http：//x.x.x.x/cj/lrcj”〉录入学生成绩〈/a〉。当然，在门户主页中，还可以增加通知公告等之类的其它常用板块。门户系统完成认证后，将生成的门户主页返回给用户浏览器。

（3）应用的CAS认证阶段。用户从门户链接列表，点击进入Web应用系统，应用系统运行其CAS入口模块，提取url中携带的ticket参数，从配置文件中读出门户的Webservice地址，以ticket为输入，向门户的Webservice接口查询用户；门户查询其数据库的ticket表，若该ticket存在，则返回对应的用户ID，说明该用户已经合法登录。否则，返回error，说明登录过期ticket被删，返回跳转，让用户重新登录门户。

（4）应用的自认证阶段。应用的CAS模块从门户的Webservice接口获得认证用户ID后，从自身数据库的用户表中检索用户ID，若不存在，则返回应用自身登录页或报出提示信息；若用户存在，则根据应用自身开发平台和设计规范，进行权限、session设置等处理。然后，取出service参数，作为应用模块的url，返回给用户浏览器，从而实现Web应用的单点登录（SSO）。

须说明，实现多系统的统一用户认证有一个前提，即应用系统的用户ID须同认证门户的用户ID保持一致或建进行映射变换，否则，应用系统无法进行内部权限的辨识。所以，统一认证的实现，还需要多系统信息同步的支持，这是数字校园建设中另一个独立的课题。

四、结语

CAS不破坏安全机制，在安全要求高的场合，也可以按X.509协议，增加证书、SSL等信任连接。但是，这种CAS模型一般只支持单向的顺序认证访问，即从CAS入口模块跳转到应用，反之，若要从应用跳转到CAS认证，则需要应用系统有较大的改动。但是，顺向的工作流程符合大多用户的登录习惯，完全能满足集成需要，是当前数字校园建设中进行系统集成务实可行的技术方案。黄石职业技术学院采用以上方案，2011年开发了数字校园统一认证和集成门户系统，运行两年来状况良好。

[1]秦怡,马自卫.基于CAS模式的统一认证与门户管理的研究与实现[J].数字图书馆,2008(1).

[2]卢清平,杨柳,许晓东.一个基于Yale-CAS的单点登录解决方案[J].合肥学院学报,2005(9).