什么是 CAS

CAS（Central Authentication Service）是耶鲁大学的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方案。采用 CAS 最大的因素是从安全性角度来考虑，用户在 CAS 服务端录入用户名和密码之后通过 Ticket 在不同系统间进行认证，不会在网上传输密码，从而保证安全性。

CAS 具有以下特点：

• 开源通用的企业级单点登录解决方案；
• 一个 CAS Server，多个 CAS Client（需要认证的 Web 应用）。
• CAS Client 支持非常多的客户端，包括 Java、.Net、PHP、Ruby 等。

CAS 单点登录原理

典型的 CAS 单点登录实现方案涉及至少三个方面：CAS Server、CAS Client（需要认证的 Web 应用）、客户端浏览器。

我们先来看 CAS 单点登录的实现流程。

首先，用户在客户端浏览器访问 Web 应用（姑且称之为应用 A），发起登录请求，Web 应用 A 会将认证请求重定向到 CAS Server，同时在客户端写入一个 Cookie，CAS Server 会验证用户是否已经认证，如果没有认证会进行认证操作（一般通过数据库进行匹配），同时生成一个 Ticket（保存起来留待后续验证时用）；然后 CAS Server 会通过带有 Ticket 的回调地址重定向回 Web 应用 A，此时 Web 应用 A 还不知道用户是否已经认证，会再次通过这个 Ticket 去 CAS Server 进行校验，如果校验通过，则从服务端删除该 Ticket，并返回认证用户信息给 Web 应用 A，Web 应用 A 根据用户信息及一开始写入的 Cookie 设置 Session，至此，用户在 Web 应用 A 中完成登录认证。

注：需要注意的是这个 Ticket 是一次性的，是与指定用户与服务相关联的，用过一次就废弃了。

如果还有另一个 Web 应用（将其称之为应用 B）此时也发起了登录请求，同样会将认证请求重定向到 CAS Server，同时在客户端写入一个 Cookie，此时用户在 CAS Server 已经处于登录状态（如果退出还需要重新登录），但是是不同应用发起的认证服务，所以，会重新生成一个 Tikcet，然后重定向回这个 Web 应用 B，同上面应用 A 的认证逻辑一样，这个 Web 应用 B 也会通过这个 Ticket 去 CAS Server 验证认证状态，验证成功后废弃该 Ticket，将用户信息返回给 Web 应用 B，应用 B 基于用户信息和一开始写入的 Cookie 设置 Session，这样 Web 应用 B 也完成单点登录。

由此可见，其实真正的登录操作是在 CAS Server（登录中心）实现的，客户端 Web 应用 A、B 都是通过 Ticket 进行登录状态验证，验证通过后各自设置 Session 完成各自系统的认证，从而实现单点登录，这个单点就是 CAS Server。

用户退出的时候，比如从 Web 应用 A 发起退出请求，会在 A 系统先退出，然后将告知 CAS Server 用户退出，这样，CAS Server 会在服务端（登录中心）将该用户退出，并且将退出消息告知其它子系统，其它子系统再各自完成退出操作，从而完成了所有系统的用户退出操作。

整个过程中，子系统与 CAS 服务端之间的交互均采用 SSL 协议（HTTPS），从而保证数据传输的安全性。我们将上述单点登录过程通过一张流程图演示如下：

整个过程应该就非常清晰了。