马凯 杨强 谢善益

摘 要：在电力企业内部网中，通过统一认证服务来实现多个Web系统间登录用户信息和状态共享已经随处可见，其中基于Apereo CAS的统一身份认证是比较常见的一种解决方式。但是Web系统单点登录只是严格限制用于那些通过浏览器访问的应用，在现如今的电力系统架构中，一套系统往往会比较复杂，可能既包含了某些Web应用，也可能会含有C/S架构的客户端、服务器或服务模块，这种混合架构场景下的统一身份认证通过基本的CAS是难以实现的。本文正是在混合结构模式下的配用电网数据管控平台之上，在保留CAS原有SSO认证过程的前提下，对其进行一定扩展，实现了C/S端跳向B/S端的统一认证过程，由此扩展了CAS的使用范围。

关键词：CAS;统一身份认证;混合架构;单点登录

DOI：10.16640/j.cnki.37-1222/t.2019.19.139

0 引言

近些年随着互联网技术和计算机技术的不断发展，电力企业中的应用系统规模越来越大、复杂度也越来越高，对系统的安全访问控制需求也越来越严格[4]。传统的单系统独立登录认证的方式，在应用系统部署较多的情况下，使得在不同系统之间切换时需要不断重复录入用户名和密码，甚至有时用户在不同系统间使用的是同一套认证信息，这无形中增加了系统使用者的麻烦，而且频繁的录入敏感信息，也增加了信息安全性风险[1-2]。因此，通过统一的认证服务来实现不同系统间用户信息共享，将各应用系统的认证过程连接起来是必然的趋势[4]。

另一方面，系统的组成也越来越来复杂，往往一套大系统内同时会包含多个子系统应用，子系统的架构类型也往往不同，一个子系统可能是浏览器/服务器（B/S）架构的Web应用，也可能为客户端/服务器（C/S）类型，亦或是移动端类型应用，这对统一认证服务的功能性提出了更高要求。

在当今的互联网应用系统中，系统的登录认证过程可以通过Oauth2.0协议获取微信、QQ、微博等等网络应用的用户信息和状态，实现统一认证和用户信息共享。但是在电力企业内部网络中，受到网络和安全管理等方面的限制，各应用系统不可能也不允许连接到外部互联网上去，因此都是通过独立部署中心认证服务器来实现单点登录及统一认证服务。

配用电网数据管控平台建立并维护配用电网全域统一信息模型，结合自组织设备接入和多源汇集规范化融合配用电业务领域系统数据，通过标准化服务为各应用提供综合数据应用支持。配用电网数据管控平台系统架构为混合架构，包含多个B/S和C/S子系统应用，平台基于开源项目CAS来实现Web应用间的单点登录[3]（Single Sign On，SSO），由于基于中心认证服务（Central Authentication Service，CAS）的單点登录严格适用于使用Web浏览器访问的应用程序，因此需要在CAS认证服务器源码额外开发新的服务扩展接口来协调平台的C/S端和B/S端之间的统一认证过程。

1 配用电网数据管控平台架构

配用电网数据管控平台完成系统部署范围内配用电网数据标准化汇集、管理及发布，包括Web应用、系统控制台及管理工具、后台服务模块服务器、Web认证服务器等几部分。

平台的Web应用系统基于CIM管控电网模型、实时、历史等各类数据，实现数据浏览及管理、系统管理、任务监测、服务器状态监测等系列功能。

系统控制台（XFront）是平台数据管理工具的启动入口，通过系统控制台窗口可以打开运行模型管理工具（XSchema）、数据管理工具（XStudio）等高级桌面维护工具，并且系统控制台的主界面能够显示当前服务器群及服务模块的实时状态概要。

后台服务模块服务器包括模型服务器、数据服务器、UA服务器、总线服务器、数据汇集任务模块等，为应用提供数据接口服务及运行保障。

配用电网数据管控平台的认证需求：

Web应用能在同一个网络内的任意计算机节点通过浏览器访问，基于CAS的Web认证服务器为Web应用提供统一认证服务。

系统控制台及其管理的高级管理工具是C/S模式的客户端程序，由维护人员进行特殊维护时使用，需要安装部署在指定的服务器，只有在指定的计算机节点才能使用。系统控制台本身具有登录访问控制功能，登录后才能启动Xschema、Xstudio等高级维护工具，系统控制台自身的登录不受Web认证服务器管理。

系统控制台同时也有链接按钮能够打开浏览器并跳转到特定Web应用页面，此时的系统控制台登录状态需要与Web认证服务器进行联动交互：当系统控制台已经是登录状态时，跳转访问的Web应用也应该是登录状态，不需要在浏览器重新登录验证。

平台混合架构示意图如图1所示。

2 CAS认证原理

开源框架Apereo CAS通常称为CAS[5]，是一种针对Web的企业多语言单点登录解决方案，并且能够成为企业系统身份验证和授权需求的综合平台。

CAS的系统架构由两部分组成：CAS服务器和CAS客户端，它们两个之间通过各种协议进行通信来完成交互认证过程。

CAS服务器：CAS服务器是基于SpringMVC和Spring Webflow框架构建的Java Servlet，主要职责是进行用户验证，并通过生成和验证Ticket（票证）来授予对CAS客户端的访问权限。CAS服务器需要独立部署。

CAS客户端：CAS客户端通常来说就是指通过协议与CAS服务器进行通信的任何CAS支持的应用程序。CAS提供了一个软件包，可以与各种软件平台和应用程序集成，以便通过某种身份验证协议（如CAS，SAML，OAuth）与CAS服务器进行通信，比如Java平台的Java Cas Client、.NET平台的.NET CAS Client、Python的pycas等等[5]。CAS客户端与受保护的客户端应用集成部署到一起。

CAS的认证核心就是票据（Ticket）。CAS的主要Ticket[6]有TGT、ST、PGT、GPTIOU、PT，其中TGT、ST是配电网数据管控平台应用中主要应用的票据，PGT、PGTIOU、PT是CAS2.0代理模式协议中用到的票据，这里不做说明。

当用户开始对CAS客户端（应用程序）某个资源进行访问时，CAS客户端判断当前是否进行过身份认证，如果没有经过认证，则会重定向到CAS服务器进行认证，客户端以过滤器的方式来实现这个过程。CAS服务器返回给浏览器一个登录认证页面，用户填写正确的信息提交给CAS服务器，CAS服务器认证成功后，会在服务器生成一个票据TGT（Ticket Granting Ticket），并且将这个TGT存放在服务器缓存，不仅如此，服务器还会在用户的浏览器生成一个Cookie TGC（Ticket Granting Cookie），TGT的ID以Cookie的形式放在这个TGC中。可以说TGT是CAS认证过程中最重要的票据，拥有TGT用户就可以证明自己在CAS服务器中成功登录过，每个登录成功会话都只保存一份TGT，并且在TGT中保存了当前登录用户的信息。TGT的核心作用是为用户签发ST（Service Ticket），顾名思义，ST是CAS为用户签发的访问某一服务的票据。如果用户在登录应用A成功后，再次提出访问应用B的某项服务的请求，应用B将请求再一次转向CAS服务器，此时CAS服务器会识别出这次请求中携带了TGC中的值，然后CAS服务器会根据这个值从服务器缓存中提取TGT，TGT签发ST并将ST返回给应用B客户端，B接收到ST后在后台以特定协议再次发送给CAS服务器确认，服务器通过认证之后将用户信息返回给应用B，应用B通过浏览器将用户请求的资源返回。上面应用B跟CAS服务器之间的交互过程，对用户来说是完全透明的，用户在浏览器中看不到票据交互过程，对用户来说只是看到了请求的页面得以正确响应而已。

CAS的传输协议使用HTTPS安全协议，保证了Cookie传输过程中的安全性，由于认证过程中使用的Cookie对象TGC只是CAS认证服务器端进行过使用，所以使得Cookie的跨域问题得到了很好解决。

整个过程完整的时序流程[5]如图2和图3所示。

3 数据管控平台Web系统的CAS应用实现

配用电网数据管控平台的Web子应用使用Java语言进行开发，CAS提供了对Java语言的支持。对CAS的集成首先需要解决的是CAS服务器和CAS客户端的集成。

CAS服务器是需要单独部署的Web服务器，CAS提供了完整的服务器工程源码，平台根据需要修改了自己风格的登录页。

CAS服務器的适配修改主要有两个步骤来实现：

（1）修改CAS服务器的用户认证过程，转换为平台认证接口，由于在用户登录过程中，为了更好的保证数据传输时的安全性，Web应用在前端对密码使用了RSA加密，所以在接收到密码的Action首先需要进行密码解密。

根据Webflow中的定义，服务器处理处理用户提交的信息是在AuthenticationViaFormAction类的submit方法进行，解密后，将用户提交信息封装成特定格式对象传递给认证处理类。

CAS在Spring配置文件中定义了认证管理器bean：authenticationManager，认证管理器的属性authenticationHandlers指定了认证用户的具体处理类，添加应用自己的处理类XOAUsernamePasswordAuthenticationHandler实现父类方法，在方法内根据平台自己的认证处理逻辑来进行用户认证，如图4所示。

（2）根据图2、图3流程图知道，在CAS服务器通过serviceValidate服务校验完CAS客户端的ST票据后，如果校验成功，需要向CAS客户端返回一个XML格式的响应，响应里包含当前认证

的用户以及一些需要传递的自定义属性。

CAS服务器实现该过程的类是ServiceValidateController，在handleRequestInternal方法中校验完成后，在casServiceValidationSuccess.jsp中定义了返回数据的XML格式，应用根据需要修改这个页面文件就可以实现向客户端返回数据。

CAS客户端是CAS提供的一套软件包，将jar包放到Web应用的classpath下，确保Web应用可以引用到。

平台Web应用的安全访问控制采用SpringSecurity实现，CAS客户端的适配修改内容也主要参照CAS官方指导中与SpringSecurity的结合说明，一些细节配置不在此叙述，其中两个较为关键的修改如下：

（1）未认证的用户请求Web应用资源，经过过滤器拦截后跳转到CAS认证服务器。在配用电网数据管控平台运行环境中，认证服务器在启动时已经向平台的后台XAgent代理模块注册，CAS客户端同样运行在平台环境中，可以通过XAgent中注册的认证服务器名动态获取认证服务器IP地址进行跳转。在调用解析认证服务器地址接口时，如果传入原始Web应用请求IP，XAgent可以根据传入IP更准确解析认证服务器地址，这在认证服务器是多IP服务器以及部署在内网进行了内外网IP映射时，解决跳转认证服务器地址不正确的问题。

（2）涉及到与认证服务器交互的编码过程都需要同上文一样动态解析认证服务器地址，另外一个需要修改请求地址的位置是客户端向认证服务器发送serviceValidate请求，以校验客户端ST的过程。CAS客户端java库使用Cas20ServiceTicketValidator类来发送该请求，在validate方法中解析认证服务器地址，然后进行转发。

4 平台混合架构下的CAS扩展方案

CAS只提供了Web应用的单点登录支持，配用电网数据管控平台需要在C/S端的系统控制台XFront打开浏览器并访问某个Web应用的资源。

CAS服务器的认证流程全部定义在Spring Webflow的配置文件中，流程起始位置是在认证服务器位置请求“/login”。创建一个为XFront认证服务的流程xfrontcheck，在这个新工作流中，流程的起始位置是在认证服务器位置请求“/xfrontcheck”。

由于没有CAS客户端与CAS认证服务的交互过程，而且由于在XFront客户端已经完成了用户的认证过程，所以不再需要CAS认证服务器常规的用户名和密码认证过程。代替的是图1所示，XFront将请求跳转到认证服务器，并且携带两个参数，一个是已经由平台认证后签发的ticket凭证字符串，另一个是认证通过后请求的原始Web应用資源地址串。这个请求串的示意样式为：https：//192.168.0.XXX：8043/xwebcas/xfrontcheck/？t=xxxxxxxxxx&s=https%3A%2F%2Fapp-a.example.com%2F，该请求在浏览器中传递，参数字符串需要进行转码传输。在CAS服务器接收到上面请求后，获取到ticket并调用平台校验接口，平台认证该ticket有效之后，CAS认证服务器认为认证成功，继续生成TGC、TGT和签发ST的过程，这个过程就与之前的过程完全一致了。

5 结论

本文基于Apereo CAS框架，实现了电力系统中配用电网数据管控平台的Web系统单点登录，实现了应用系统的统一管理，有效解决了用户在多个应用系统之间频繁登录的问题，提高了系统操作便利性和系统安全性。

另外，在此基础上，对CAS的SSO认证过程进行了扩展，改造了现有平台认证模式，在平台认证体系中增加用户认证凭证概念，并由此实现了C/S端跳向B/S端的统一认证过程，扩展了CAS框架的使用范围，为之后的混合架构下多端统一认证研究提供了一种可参考范例。

参考文献：

[1]沈杰，朱程荣.基于Yale-CAS的单点登录的设计与实现[J].计算机技术与发展，2007，17（12）：144-146+150.

[2]李建佳，王晶.基于JA-SIG CAS统一认证平台（SSO）的设计与实现[J].广东海洋大学学报，2013，33（03）：78-83.

[3]施正晔.SSO单点登录模型的优化研究[J].计算机光盘软件与应用，2012（S1）：190-191.

[4]呼和，张钦，陈国青，杨旸.基于Web服务的企业统一认证与授权系统[J].计算机应用，2011，31（02）：577-580.

[5]Aperea CAS.Enterprise Single Sign-On for All[DB/OL]. https：//apereo.github.io/cas/4.2.x/index.html.

[6]王永.基于CAS和Shibboleth的单点登录研究与设计[D].成都：电子科技大学，2011.