保留原系统账号登录的CAS单点登录改进方法

2018-07-12董恒竞宫大伟雷远东

电脑知识与技术 2018年12期

董恒竞宫大伟雷远东

摘要：随着企业信息化的不断发展和应用系统规模的不断扩大，企业逐渐出现了对多应用系统实现单点登录（SSO）功能的需求。CAS是一款开源的单点登录产品，基于CAS对企业应用系统进行单点登录改造，可以达到单点登录的目的。但由于各种历史原因，企业应用系统都有着不同的账号体系，账号又与业务流程、数据存储紧密联系。所以在单点登录改造过程中，许多应用系统都希望保留原来的账号体系。基于此问题，该文提出了一种对CAS产品进行改进的方法，在不改变原系统账号体系的条件下，使得用户可以使用多种应用系统的账号进行登录，降低了企业应用系统单点登录改造的复杂度，使得单点登录在企业内更易于实现。

关键词：企业信息化；单点登录；中心认证服务；轻量目录访问协议；企业门户

中图分类号： TP311 文献标识码： A 文章编号：1009-3044（2018）12-0235-04

Abstract： With the enterprise informatization， there are more and more applications in enterprises. Many enterprises have the requirement to realize the single sign-on functions. CAS is an open-source product to fix this requirement. However， due to various historical reasons， enterprise applications have different account systems. And the accounts have a close contact with the business processes， data storage， and so on. So many applications hope to retain the original account systems. Based on this problem， this paper proposes a method to make CAS to accept the original system accounts， the applications use old system accounts easily， to make the applications to have lest changes. The practice proved that this strategy makes single sign-on easier for the enterprise to realize.O

Key words： Informatization； Single Sign-On （SSO）； Central Authentication Service （CAS）； Lightweight Directory Access Protocol （LDAP）； Enterprise Portal

1 背景

隨着企业信息化的不断推进，企业应用系统的数量越来越多，这些应用系统一般是在不同时期，采用不同的技术、架构开发的，都有着独立的用户信息库和认证体系。用户在使用不同系统时，需要输入不同的账号（密码）进行登录。单点登录（Single Sign-on，SSO）概念的提出是企业信息化不断深化以及网络应用不断推广的必然结果[1]。

单点登录是一种方便用户访问多个应用系统的技术。在对企业应用系统进行单点登录改造后，用户只需登录一次，就可以在多个应用系统间自由切换[2-3]。单点登录是企业门户建设需要解决的首要问题[4]。

实现单点登录的技术有很多，有基于经纪人、基于代理人、基于网关、基于Cookie及基于SAML等，针对不同架构系统使用不同的认证方式[5]。基于不同技术，存在很多单点登录软件。其中，开放源码的单点登录软件有， SUN支持的OpenSSO，JOSSO，美国Internet2高级网络联盟（MACE）小组开发的Shibboleth系统以及Yale大学发起的CAS项目等等[6]。

2 CAS产品

2.1 CAS简介

CAS（Central Authentication Service）是由Yale大学发起的，并在2004年12月正式成为JA—SIG的一个项目。CAS产品为Web应用系统提供了一种可靠的单点登录实现方法，是目前比较流行的服务于企业单点登录的解决方案之一[7]。

CAS包含两个部分：CAS Server和CAS Client。CAS Server独立部署，负责对用户信息的认证工作。CAS服务器提供了一套易于定制的用户认证器接口.用户可以根据自身企业的在线系统的认证方式，来定制自己的认证逻辑。CAS Client负责处理对客户端受保护资源的访问请求，需要登录时重定向到CAS Server[8]。

2.2 CAS的基本协议

如图1，CAS访问流程主要有以下6个步骤[8-9]：

1）访问服务（CAS Client）：用户通过客户端浏览器发送请求，访问应用系统提供的服务资源。

2）重定向（Service）认证：CAS 客户端收到用户请求后，重定向用户请求到CAS服务器。

3）用户认证：用户输入信息进行身份认证。

4）发放票据（Service Ticket）：CAS 服务器会产生一个随机Service Ticket。

5）验证票据：CAS 服务器验证票据Service Ticket的合法性，验证通过后，允许用户访问服务。

6）传输用户信息（Principal）：CAS 服务器验证票据通过后，传输用户认证结果信息给用户。

CAS基本的协议过程如下[9]：

和CAS Client安放在一起的是受保护的客户端应用系统，利用Filter请求进行过滤方式。若受保护的资源被每个Web 请求访问，则CAS Client 就会对该请求进行立即分析，对Http请求中是否包含Service Ticket进行查看，并将请求向CAS Server登录地址发送，并且将Service传递（也就是要访问的目的资源地址），而一旦登陆成功，则可向该地址转回。

用户则在第3步中将认证信息输入，CAS Server就会随机将一个字符数生成，Service Ticket是不可再造的、唯一的，为了将来验证需要进行延缓，之后对Service所在的地址，系统自动重新登陆，并将一个Ticket Granted Cookie配置到客户端浏览器配置，在拿到Service和新生成的Ticket 之后，CAS Client 在第5、6步中与CAS Server 进行身份验证，对Service Ticket的正确性提供保障。全部与CAS的交互在这个协议中，都利用SSL协议，进而对ST和TGC的安全性提供保障。在工作过程中，该协议将两次重新回到Service所在的地址，验证用户能够见到CAS Client与CAS Server之间进行Ticket验证的过程。

2.3 CAS的优点

CAS开源产品具有如下优点[10]：

1）配置简单：CAS Server基于Spring Framework编写，对其管理，大多只需通过配置即可；

2）支持多种认证接口：CAS Server提供了一套易于定制的用户认证器接口，不论是传统的用户名/密碼方式、还是采用LDAP服务器，都可以通过对验证器模板稍加修改，便可使用；

3）松散耦合：CAS被设计成可独立部署的B/S Web应用，Server与Client分开实现，降低了认证模块与应用系统的耦合度，提供了更好的SOA设计和更弹性的安全策略；

4）多语言支持：CAS Client支持多种语言的客户端，如Java、.NET、PHP、Perl、Ruby等；

5）安全性高：在CAS协议中，所有与CAS的交互均采用SSL协议，保证了系统安全性；

6）支持复杂环境应用：CAS 2.0协议扩展了Proxy（代理）认证，Web应用可作为代理，访问其他的Web应用。从而使CAS可支持更高级、更复杂的应用场景。

3 问题分析

基于CAS对企业应用系统进行改造，可以实现用户单点登录的目的[11]。对于新上线的应用系统，则可以完成由CAS服务器来接管用户身份的认证。对于已经上线运行的应用系统，由于这些系统往往有着独立的账号数据和认证机制，而且企业有很多业务流程涉及用户信息，单点登录的实现应该尽量不要影响到这些应用系统的原认证模块和具体的业务流程[12]。

论文[7]通过用户映射（见图2），将CAS人员信息与这些业务系统的人员信息关联起来，当用户在经过CAS认证之后，这些业务系统就可以正确识别用户的身份并进行授权，以实现单点登录的目的。这种模拟登录机制是针对那些基于Form表单方式登录的Web应用系统设计的，它不需要对应用系统的原有认证模块做任何修改。

建立用户映射表之后，实现应用系统模拟登录的方式有：

1）提供一种应用登录插件，并在CAS认证客户端安装该插件。通过插件的接口支持来完成自动填写用户名和密码，并提交应用系统的登录Form结果，以实现模拟登录。

2）由应用系统提供Web Service接口，CAS认证中心只负责提供当前通过认证的用户映射信息，登录由该Web Service接口实现，该方式适用于企业内部，安全性要求不高的应用。

然而，在本企业中，因为应用系统的密码都是密文存储，而且企业信息安全制度也不允许建立这样包含明文密码的数据表。这样使得通过用户/密码映射模拟用户登录的方法，在本企业中很难应用。

于是，该文提出了另一种较安全、保留原系统账号登录的CAS单点登录改进方法。

4 CAS改进方法

4.1改进的总体设计

该文的设计目的是在单点登录服务器中不存储用户账号/密码的条件下，允许由用户选择采用具体哪一套应用系统的账号、密码进行单点登录。

设计模型图见图3。

根据该设计，在单点登录服务器的数据库中存储根据App1和App2（及更多）本身账号库建立的账号映射表。在用户通过Web浏览器访问App1的受保护资源时，App1会通过CAS Server进行用户登录、验证。CAS Server根据用户的输入会选择时通过App1的账号库进行验证（或选择App2的账号库），验证通过后，会给App1应用系统返回根据账号映射表构造的用户信息。

基于CAS开源产品，进行保留原系统账号登录的单点登录改进方法有如下特点：

1）通过账号同步程序，定时同步用户账号信息，不同步账号密码，避免密码泄露的问题。这种方法可以适用于密码加密，或密码不可读的应用系统，也比模拟各应用系统登录的方式更加安全。

2）在应用系统（CAS Client）中，增加了账号过滤器，使得应用系统直接获得本应用系统的账号（登录），避免了对应用系统原业务流程的干扰，使得单点登录改造更简单化。

3）对于分配给部门、传真等不能映射到具体人员的账号，或者管理员账号，允许使用原账号进行登录。这样，不需要再给这些账号设立假的单点登录标准账号（一般是工号或者LDAP账号）。使得这种仅用于个别系统的不针对具体个人的账号，不扩散，仍然限制在本应用系统中。

4.2 CAS Server的改进

给每个应用系统的账号库（也可能多个应用系统采用一个账号库），分配一个账号类型，如WORKNO， LDAP， OA等等。在应用系统账号库中增加账号信息的关键字段，如工号（或者LDAP账号，应用系统维护该关键字段的数据）等，关键字段唯一标识该账号属于哪一个人。

设计同步程序，从各应用系统中同步账号，并根据关键字段构建账号映射表（见表1）。关键字段可以为空，这时该账号不与其它应用系统的账号关联，单点登录后仅能使用本系统。同时，因为关键字段可以为空，所以才不能使用关键字段作为单点登录的ID（在Principal中）。

在CAS Server的开源代码中，修改认证凭据类、验证处理类。在验证凭据类中增加账号类型属性。在验证处理类中增加一个“支持验证的账号类型”的属性，并重写其supports函数，使得一个处理类实例只处理特定类型的账号类型的登录输入。改造后的CAS Server验证处理流程如图4。

这样，在客户端登录时，需要向服务器传送账号、密码、账号类型三个属性。CAS Server根据接收的账号类型，分别交由不同验证处理类的实例进行验证，验证通过后，由Principal解析器解析用户信息（通过用户映射表）向客户端提供用户信息（在Principal的attributes属性，账号类型到账号的映射）。

实现结果，该企业中有多个验证处理器，其中OA系统的验证处理器配置文件如下XML配置。这样，在用户登录选择OA系统账号进行登录时，验证过程将由本验证处理器承接。具体验证过程为：通过sql语句到MSSQL_OA的数据源中比较加密后的用户输入密码与存储密码是否一致。

class="AccountTypeQueryDatabaseAuthenticationHandler">

4.3 CAS Client的改进

进行CAS Client代码改造，主要是新建账号过滤器，由该过滤器实现从Principal对象中解析用户信息。建立账号登入/登出处理接口，用户只用特定的配置（账号管理器的注册）和实现（账号登入/登出处理接口的实现），就可以实现对原用户验证过程的替代。具体过程如下：

1）在应用系统配置文件（例如J2EE Web工程的web.xml文件）中，注册账号过滤器（在CAS原过滤器之后）。并给过滤器设置两个参数，一个是应用系统账号类型（如OA），一个是账号登入/登出处理器。

2）在账号过滤器中，从“_const_cas_assertion_”的session变量中解析用户信息（Principal），从用户信息的用户映射Map（Principal的attributes属性）中，根据账号类型（如：OA），取出当前应用系统的账号（如：zhangsf）。

3）在账号过滤器中，调用账号登入/登出处理器。处理器一般是通过设置session等变量进行用户登入，然后进行登入日志记录等后续操作。

4）在登出時，账号过滤器同样调用账号登入/登出处理程序，进行session等变量的擦除，进行登出后日志记录等后续操作。

4.4 对于一系统多账号的支持

对于一些应用系统，特别是开发时间较长的应用系统，由于其不是基于角色开发的。而在实际企业中，存在一些人兼职的可能。这样在系统管理中，往往最简便的方法是给这些人多开一个账号。这样，在同一个系统中就存在同一个人对应多个账号的情况。

我们的设计策略是，在CAS Server的Principal解析器中将同一个人的多个账号，通过分隔符组成一个字符串。例如，对应于表1中的OA系统的账号（返回给Client）是zhangsf：：zhangsf1。通过解析，客户端的账号过滤器将获得两个账号，分别是zhangsf和zhangsf1。在门户系统中，显示一个由CAS服务器提供的应用系统列表。默认，应用系统链接处不显示账号信息。但在存在多个账号时，应用系统链接默认是使用第一个账号登录，链接后会显示详细的账号名，可以由用户支持采用哪个账号进行登录。具体用哪个账号登录，由账号过滤器根据传递的参数（账号顺序号）进行选择。

4.5 对于验证且总放行页面的支持

对于CAS客户端的页面，默认是分为保护资源和非保护资源。访问保护资源时，需要进行单点登录验证。验证通过，就放行，让Web浏览器继续访问受保护资源。如果验证不通过，则跳转到CAS服务器的登录页面。

然而，在实际的应用中，存在一种需要验证但总放行的情况。也就是在用户未登录时，也允许访问，但需要获得用户的是否登录及登录信息。例如门户页面，在用户未登录时，可以访问，显示的是新闻类内容；在用户登录后，不仅显示新闻类内容，还要显示账号信息和待办事宜等等。

默认的CAS访问保护机制是不支持这种情况的。我们通过以下两项开发解决该问题：

1）在CAS Server上，参考默认的验证流程（参考：login-webflow.xml文件），新建了一个验证并返回的流程。在通过该流程进行验证时，无论是否验证通过，都进行到原资源的跳转（默认是到CAS的登录页面）。

2）在CAS Client上，新建了一种验证并返回的过滤器，在没有登录时，过滤器才起作用。根据session中的一个BOOL型变量的值，判断是否进行验证跳转。在没有登录时，如果变量值为FALSE，先将值改为TRUE，再进行到CAS服务器的验证跳转；如果值为TRUE，则直接访问系统页面。

这样，用户在访问该类页面时，实际会进行两次访问。第一次进行用户的验证，第二次无论是否验证通过都放行。页面就可以根据用户是否登录，进行不同页面内容的显示。

4.6 其他建议与应用

1）虽然该文给出了使用各应用系统原账号进行单点登录的方法，但仍建议建立企业的LDAP服务器，将LDAP账号作为单点登录的首选账号，将其他应用系统的账号作为备选账户。这样做，是由于用户习惯一个账号后，就会逐渐忘记其他登录方式，而大家优先使用LDAP账号，便于企业推进统一的账号管理。建议企业新上线的应用系统，使用LDAP的账号管理，不要再新建更多的账号库。

2）对于WebSphere集群部署的应用，原代码存在单点登出失败的可能，可以通过修改CAS服务器代码得以解决。在Java类org.jasig.cas.util.HttpClient的登出代码中增加JSESSIONID，使得WebSphere集群能够将登出请求分配到正确的节点。

3）对于基于Lotus Domino开发的Web应用的单点登录改造，可以通过DSAPI（Domino Web Server AppIication Programming Interface）技术进行开发[10]。开发过程这里就不再叙述了。

论文中的改进方法，已在作者企业中得到了实际应用，单点登录登入界面如图5。其中，本企业采用工号作为用户登录的首选账号类型，同时允许其他系统原账号的登录。

5 结束语

CAS（Central Authentication Service）是一款很好的开源单点登录软件，基于它可以很好的实现企业级的WEB应用系统单点登录功能。但结合自身企业的不同特点，还需要对其进行一定程度的改进。该文介绍了如何进行对应用系统影响较小的，支持应用系统原账号登录的CAS开发改进方法。

在该企业进行应用的过程，证明了论文阐述的方法可以在遵守企业信息安全制度的条件下，有效降低企业应用系统单点登录改造的难度，增强用户的可接受程度。这应该对其他企业单点登录实践有一定的参考意义。

参考文献：

[1] 吴晓洁. 基于CAS的单点登录系统的实现[J]. 科技信息， 2013（26）： 289-200.

[2] 林满山，郭荷清. 单点登录技术的现状及发展[J]. 计算机应用， 2004， 24（z1）： 248-250.

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

[4] 谭立球，费耀平，李建华，等. 企业信息门户单点登录系统的实现[J]. 计算机工程， 2005， 31（17）： 102-104.

[5] 骆嘉伟，唐国英. 区域卫生信息化中单点登录系统的设计与实现[J]. 计算机应用， 2012， 32（6）： 1782-1786.