使用 CAS 在 Tomcat 中实现单点登录

张 涛 和 王 秉坤

2008 年 4 月 10 日发布

CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点：

我们知道，http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。对stash进行访问，肯定是需要进行认证后方能访问，stash里的访问登录一般都是接入公司的认证体系，因为每个公司的认真方式都是不同的，需要我们使用中间人工具拦截并分析认证的通信消息，然后对这些交互消息进行逐条分析，并使用代码实现自动化的模拟登录，一般stash的认证后的凭证是生成一个访问git的session_id。[0002]单点登录技术是在通过vpn客户端认证成功后，用户请求访问受vpn网关保护且支持单点登录的后台应用时，vpn网关通过匹配的单点登录用户信息重新组装用户访问请求数据包，以实现对后台应用的自动认证，而无需用户再次填写用户信息。

CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份合适，以确保 Service Ticket 的合法性。

在该协议中，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。

另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。

本文中的例子以 tomcat5.5 为例进行讲解，下载地址：

到 CAS 官方网站下载 CAS Server 和 Client，地址分别为：

微服务采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，例如 rpc、http 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。先进的组件架构以全局单事件完整套件部署，兼容两层应用策略部署。产品顾问支持，以满足客户需求为基础，量身打造定制化服务，完成设备的功能扩展、协议对接和兼容反馈。

在 Tomcat 上部署一个完整的 CAS Server 主要按照以下几个步骤：

如果希望 Tomcat 支持 Https，主要的工作是配置 SSL 协议，其配置过程和配置方法可以参考 Tomcat 的相关文档。不过在生成证书的过程中，会有需要用到主机名的地方，CAS 建议不要使用 IP 地址，而要使用机器名或域名。

在客户端登录，这时不能使用ftp01、ftp02登录了，因为他们登录进去后直接到了站点根目录下的对应子目录下了，同时不能向上回到站点根目录，所以只能另外创建新用户，这里我创建了一个ftp03用户，登录进去发现除了可看见ftp01、ftp02目录外，还有其他目录，但是前面设置了ftp01，ftp02目录的权限，所以ftp03并不能访问他们，只是知道这些目录的存在而已。domain目录服务器目录applications，将应用目录放在此目录下将可以作为应用访问，如果是web应用，应用目录需要满足web应用目录要求，jsp文件可以直接放在应用目录中，javabean需要放在应用目录的web-inf目录的classes目录中ibm portal 单点登录，设置服务器的缺省应用将可以实现在浏览器上无需输入应用名。其实访问web应用中被保护的页面，使用浏览器则十分简单，用户通过系统提供的登录页面登录系统，浏览器会负责维护与服务器之间的sesion，如果用户登录的用户名、密码符合要求，就可以访问被保护资源了。

浏览器控件是个典型的active控件，提供了大量的接口及自动化对象，可以灵活的加以控制，需要的时候，可以通过这些接口控制浏览器的行为，或提供相应的出接口定制浏览器。yiui易柚电视操控系统在电视功能、网络通讯、外置存储、标准ui类库等方面都作了深度扩展和定制，并基于android底层和应用层搭建了自己的中间件系统，将yiui易柚电视操控系统的扩展接口标准化，解决了应用开发接口的统一问题，通过标准化后的扩展接口，定制出了康佳的百变主题，且在各个平台上可以无缝移植。推出了以下新的支持库：农历月历支持库中新增“农历月历”组件拖放支持库正则表达式支持库进程通讯支持库bt下载支持库网络通讯支持库二扩展界面支持库三中增加“高级选择夹”组件应用接口支持库opengl支持库directx发支持库sqlite支持库控制台操作支持库扩展界面支持库五20。

CAS Server 负责完成对用户的认证工作，它会处理登录时的用户凭证 (Credentials) 信息，用户名/密码对是最常见的凭证信息。CAS Server 可能需要到检索一条用户帐号信息，也可能在 XML 文件中检索用户名/密码，还可能通过 LDAP Server 获取等，在这种情况下，CAS 提供了一种灵活但统一的接口和实现分离的方式，实际使用中 CAS 采用哪种方式认证是与 CAS 的基本协议分离开的，用户可以根据认证的接口去定制和扩展。

扩展 AuthenticationHandler

CAS 提供扩展认证的核心是 AuthenticationHandler 接口，该接口定义如清单 1 下：

public interface AuthenticationHandler {
    /**
     * Method to determine if the credentials supplied are valid.
     * @param credentials The credentials to validate.
     * @return true if valid, return false otherwise.
     * @throws AuthenticationException An AuthenticationException can contain
     * details about why a particular authentication request failed.
     */
    boolean authenticate(Credentials credentials) throws AuthenticationException;
/**
     * Method to check if the handler knows how to handle the credentials
     * provided. It may be a simple check of the Credentials class or something
     * more complicated such as scanning the information contained in the
     * Credentials object. 
     * @param credentials The credentials to check.
     * @return true if the handler supports the Credentials, false othewrise.
     */
    boolean supports(Credentials credentials);
}

该接口定义了 2 个需要实现的方法，supports ()方法用于检查所给的包含认证信息的Credentials 是否受当前 AuthenticationHandler 支持；而 authenticate() 方法则担当验证认证信息的任务，这也是需要扩展的主要方法，根据情况与存储合法认证信息的介质进行交互，返回 boolean 类型的值，true 表示验证通过，false 表示验证失败。

在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。 难以支持新种类的产品，这是因为抽象工厂接口确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将引起抽象工厂类及其所有子类的改变。的来说，面向接口应该是面向对象中的一部分吧，因为面向对象也强调的是依赖倒置原则，也就是实现依赖于抽象，而抽象不依赖于具体实现，更具比较的应该是面向接口与面向抽象对象，我的体会是面向接口更加灵活，但实现时候，稍微有些代码冗余，而面向抽象可以结合面向接口，先定义接口，再定义抽象类，在抽象类中处理一些公共逻辑，再实现具体实现类。

public abstract class AbstractPreAndPostProcessingAuthenticationHandler 
                                           implements AuthenticateHandler{
    protected Log log = LogFactory.getLog(this.getClass());
    protected boolean preAuthenticate(final Credentials credentials) {
        return true;
    }
    protected boolean postAuthenticate(final Credentials credentials,
        final boolean authenticated) {
        return authenticated;
    }
    public final boolean authenticate(final Credentials credentials)
        throws AuthenticationException {
        if (!preAuthenticate(credentials)) {
            return false;
        }
        final boolean authenticated = doAuthentication(credentials);
        return postAuthenticate(credentials, authenticated);
    }
    protected abstract boolean doAuthentication(final Credentials credentials) 
throws AuthenticationException;
}

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-117269-1.html