本文简要介绍了CAS流程、对接CAS的适配点，并提供了demo级实战参考链接。
CAS的原理并不复杂，只要弄清楚整个流程就能很快将自己的Web服务对接上CAS Server。
CAS登录总体流程
总体来讲，CAS登录的流程如下图：
- 用户访问Web服务，Web服务通过查询Session（一般是缓存，也可以把登录状态存到别的地方）检查用户是否已登录。若未登录，将用户请求重定向到CAS登录页面。。若已登录，就直接返回受限制资源给用户，登录流程结束。
- CAS Server收到请求后，首先通过查询CAS的Session检查用户是否已登录。若未登录，返回CAS登录页面给用户。 若已登录，就直接返回Ticket给用户。
- 用户收到（跳转到）CAS登录页面后，输入用户名和密码，发送给CAS Server。
- CAS Server收到请求后，首先验证用户名和密码是否正确，验证通过后创建新的CAS Session和CAS Ticket。同时，将请求带上Ticket参数，并重定向到Web服务的CAS认证接口。
- 用户收到重定向响应后，立刻自动向Web服务的CAS认证接口发送请求。
- Web服务的CAS认证接口接收到用户的Ticket后，会将Ticket发送到CAS Server进行验票，验票通过后，Web服务会创建新的web session（一般会创建session，但是不一定，因为验票通过后的行为是由开发者自定义的），将请求重定向到原先的受限资源。
- 用户收到重定向响应后，请求受限制资源，Web服务通过查询Session发现用户已登录，直接返回原先访问的受限制资源，流程结束。
一些注意点
- 当我们的请求被重定向到CAS Server时，CAS本身是不知道后续需要跳转到Web服务的哪个地址的，所以当Web服务将请求重定向到CAS时，一般都会带上一个参数"service=XXX"，表示后续请求应该跳转到哪个URL。
- Ticket相当于CAS Server发放给用户的一张临时票券，用来登录指定的Web服务。因此，将请求重定向到“Web服务的CAS认证接口”的现实意义是：将Ticket交给Web服务，告诉它用户要用这个Ticket来登录Web服务。 所以，Web服务自然要请求CAS Server来验证票据的真伪。
- 对于流程中的第7步，Web最后未必会将用户请求重定向回原先访问的受限制资源，实际上这是一个可由开发者自定义的行为。 有些Web服务会直接重定向回首页，有的Web服务会在用户第一次访问时，将他访问的地址存在缓存里，认证通过后从缓存中取出并作为重定向目标，以此来实现第7步描述的效果。（当然实现方法不止一种，也可以存在用户cookie里等等。）
了解流程对于对接CAS的指导意义
从以上流程中可以看出，Web服务对接CAS主要做5个配置（与流程图中的序号对应，）：
- 配置CAS登录页面URL，用户未认证时，需要重定向到的CAS登录页面。
- 配置CAS认证接口URL，Web服务将在这个接口上监听用户的CAS Ticket。
- 配置CAS Ticket验证接口URL，Web服务接收到用户的CAS Ticket后，需要发送到CAS的Ticket验证接口验票。
- 配置认证成功后的重定向URL，认证成功后Web服务会将用户请求重定向到这个URL。
- （可选）以上几个配置都是Web服务侧的，而最后一个配置是：CAS Server侧需要对接用户信息系统，用于账号密码验证。若CAS已有对接，则不需要。
实战链接
若看官希望深入了解CAS流程，建议实操一下。用Docker部署CAS再用在本地用SpringSecurity对接一下CAS，参考以下文章：
Docker部署简单CAS Overlay
Spring Security对接CAS
知识链接
Spring Security官方解释了CAS流程，介绍了利用Spring Security对接CAS后，每个登录流程都是由哪些类在控制，推荐结合实践阅读。
Spring Security官方解释CAS流程
