SSO(Single Sign On)单点登录系统，是在多个系统中值要求只要登录一次，就可以用已登录的身份访问多个系统，去掉了每次访问不同的系统都要重新登录的弊端。
CAS(中央/集中认证服务)：The Central Authentication Service project, more commonly referred to as CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user.
CAS是实现SSO的一个开源项目，最初由耶鲁大学创建。很明显冲名字就可以看出其原理是：多个系统使用一个相同的“中央认证服务”来实现的。
1. CAS 架构：
1) 系统组成：分成了一个 CAS server 和 多个CAS clients 两大物理组成部分。
2）CAS Clients
The term “CAS client” has two distinct meanings in its common use. A CAS client is any CAS-enabled application that can communicate with the server via a supported protocol. A CAS client is also a software package that can be integrated with various software platforms and applications in order to communicate with the CAS server via some authentication protocol (e.g. CAS, SAML, OAuth). CAS clients supporting a number of software platforms and products have been developed.
CAS clients: 也就是 多个业务系统。我们用户在访问业务系统时，业务系统作为 CAS client, 来访问CAS server进行认证。实现方式是，将我们redirect到CAS server上，然后我们输入用户名密码，CAS server进行认证。所以相对于CAS server，我们用浏览器访问多个业务系统就是 CAS clients。
3）CAS Server
The CAS server is Java servlet built on the Spring Framework whose primary responsibility is to authenticate users and grant access to CAS-enabled services, commonly called CAS clients, by issuing and validating tickets. An SSO session is created when the server issues a ticket-granting ticket (TGT) to the user upon successful login. A service ticket (ST) is issued to a service at the user’s request via browser redirects using the TGT as a token. The ST is subsequently validated at the CAS server via back-channel communication. These interactions are described in great detail in the CAS Protocol document.
CAS server是一个基于spring的系统，其首要职责就是对登录用户进行认证，然后授权给它们去访问“业务系统”也就是CAS clients。其实现方式：发出票据和验证票据。比如，一个用户要登录一个“业务系统A”，那么该业务系统，将我们重定向到 CAS server, 然后我们输入用户名和密码等，然后CAS server进行认证，也就是验证用户名和密码是否正确，如果正确，就发给我们一个 TGT 票据，然后针对该“业务系统A”， CAS server 又根据TGT 生产一个专门针对该业务系统的 ST 票据。然后如果我们又去访问另外一个“业务系统B”，那么这个“业务系统B”又将我们重定向到 CAS server,但是这一次，我们携带了 TGT 票据，我们不用再次输入用户名和密码，CAS server 会根据我们的 TGT 针对该“业务系统B” 又生产一个专门针对该业务系统的 ST 票据。 然后我们又要访问“业务系统A”，此时我们有了 TGT 和 针对“业务系统A”的 ST 票据，这次，业务系统A会将自己的 ST 票据，发送给 CAS server 进行验证，如果存在。那么就认证通过。
总结一下：
1>第一次没有 TGT 和 ST 票据，需要输入 用户名和密码 在 CAS server上进行认证；
2>认证通过之后会 生成 TGT 票据和针对该 CAS client 的 ST 票据；
3>有了 ST 票据之后，CAS client 将 ST 票据发送给 CAS server 进行查找，如果存在则通过认证；
4>如果只有 TGT 票据，那么将 TGT 票据发给 CAS server，生成一个专门针对该 CAS client 的 ST 票据；
5> TGT 票据应该是基于cookie，也就是保存在cookie中的，而各个业务系统的 ST 票据是保存在自己的业务系统的内存中的；
4）第一次登陆时的交换图：
5)Software Components
It is helpful to describe the CAS server in terms of three layered subsystems:
- Web (Spring MVC/Spring Webflow)
- Ticketing
- Authentication
Almost all deployment considerations and component configuration involve those three subsystems. The Web tier is the endpoint for communication with all external systems including CAS clients. The Web tier delegates to the ticketing subsystem to generate tickets for CAS client access. The SSO session begins with the issuance of a ticket-granting ticket on successful authentication, thus the ticketing subsystem frequently delegates to the authentication subsystem.
The authentication system is typically only processing requests at the start of the SSO session, though there are other cases when
it can be invoked (e.g. forced authentication).
CAS Server 系统的架构有三部组成(三个子系统)： 1> web端；2> 票据系统; 3>认证系统；
web端代理了 CAS clients，来向票据系统申请票据和验证票据，票据系统根据要求产生票据和验证票据；而认证系统就是对输入的用户名和密码进行验证，验证成功之后，通知票据系统生成票据。所以认证系统只有在第一次登陆时才会使用到。票据系统应该是三个子系统中最繁忙的。
参考：
1）http://jasig.github.io/cas/4.0.x/planning/Architecture.html
2）http://sowow.sinaapp.com/archives/57
3）http://jasig.github.io/cas/4.0.x/index.html