简介
Cas介绍
CAS （ Central Authentication Service ），最初由耶鲁大学的Shawn Bayern 开发，后由Jasig社区维护，经过十多年发展，目前已成为影响最大、广泛使用的、基于Java实现的、开源SSO解决方案。cas旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。 CAS 开始于 2001 年， 并在 2004 年 12 月正式成为 JA-SIG 的一个项目。
CAS的官方网址是： https://www.apereo.org/projects/cas
工程代码网址：https://github.com/Jasig/cas
架构
CAS应用的整体架构官方提供了一个比较清晰的架构图，如下所示：
主要特性
SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。
一般场景下，我们不需要重新造轮子，直接在成熟技术框架基础上开发使用即可。这也是CAS在很多互联网和企业应用中广泛使用的原因。当然，对于某些场景，如安全性因素、扫码登录、更特殊更高效的应用场景，在技术实力许可的情况下，通常都自己实现SSO，当然，也可以自定义CAS。
我粗略的罗列一些CAS的优势：
1、 开源的、多协议的 SSO 解决方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。
2、 支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等，可自定义；
3、 安全策略：使用票据（ Ticket ）来实现支持的认证协议；
4、 支持授权：可以决定哪些服务可以请求和验证服务票据（ Service Ticket ）；
5、 提 供高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现， 如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；
6、 支持多种客户端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。
单点登录流程概述
协议过程
如 上图： CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同 时， CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket( ST 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的；于是 CAS Client 会重定向用户请求到 CAS Server （ Step 2 ），并传递 Service （要访问的目的资源地址）。 Step 3 是用户认证过程，如果用户提供了正确的 Credentials ， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，并且重定向用户到 Service 所在地址（附带刚才产生的 Service Ticket ） , 并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ） ； CAS Client 在拿到 Service 和新产生的 Ticket 过后，在 Step 5 和 Step6 中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。
在该协议中，所有与 CAS Server 的交互均采用 SSL 协议，以确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向 的过程。但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的（使用 HttpsURLConnection ）。
认证时序图
官方的用户登录时序图非常详细，直接引用如下：
所有的系统应用都会引导到CAS Server认证中心去登录。登录成功后，认证中心会产生一个票据叫TGT(Ticket Granting Ticket)，TGT即代表了用户与认证中心直接的全局会话。TGT存在，表明该用户处于登录状态。
TGT并没有放在Session中，也就是说，CAS全局会话的实现并没有直接使用Session机制，而是利用了Cookie自己实现的，这个Cookie叫做TGC(Ticket Granting Cookie)，它存放了TGT的id,认证中心服务端实现了TGT。
在认证中心登录下，看下登录前后cookie的变化。显然，在登录后，多出一个叫CASTGC的Cookie,它来维持全局会话。
如果是应用系统登录，客户端会被引导到认证中心进行登录，登录成功后再重定向回应用系统，这时会带上一个登录令牌，告知系统应用登录成功。
这个令牌，在CAS中叫做ST(Service Ticket)服务票据，它的作用和Nebula的token类似。当然，和Nebula一样，应用系统收到ST后，会直接向CAS Server去验证，验证通过后，应用系统即可建立本地会话，返回用户访问的受限资源。
其中第一个，我们看到，登录成功后，系统会设置CASTGC Cookie，同时重定向回应用时带上了一个ticket变量，这个就是ST。
小结
CAS 已经有很多公司在实际项目中应用，可以肯定它的可靠性，它可以解决项目中大部分单点登录的场景，由于他采用spring mvc, spring webflow方式开发，项目结构是模块化的，即使默认提供的功能不能满足业务场景，如扫码登录，我们也可以很方便的扩展这个功能。后期我会写一篇关于如何自定义的文章。
参考
cas Architecture
《SSO CAS单点系列》之 实操！轻松玩转SSO CAS就这么简单(相遇篇)
《SSO CAS单点系列》之 实操！轻松玩转SSO CAS就这么简单(相识篇)
