Authentication Service (AS) --------- 认证服务，索取 Crendential ，发放 TGT ；
Ticket-Granting Service (TGS) --------- 票据授权服务，索取 TGT ，发放 ST 。
CAS协议和工作流程
下图是 CAS 最基础协议：
1 、 CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求， CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket （ ST ）和 Ticket Granting tieckt(TGT) ，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ）， CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5 ， 6 步中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。
2 、在该协议中，所有与 CAS 的交互均采用 SSL 协议确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
3 、 CAS 如何实现 SSO
当用户访问另一服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：
1) 如果 User 的持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果；
2) 如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。
另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。
cas的验证流程
1. 用户浏览受系统保护的URL。
2. CAS Client服务端收到请求，Filter拦截该请求，在Filter中判断该用户是否已经登陆，如果已经登陆，就直接进入系统，否则，将请求转发到CAS Server服务端的LoginURL。
3. 在LoginURL中会获取到用户的Cookie，检验用户是否已经在其他相关使用SSO的系统登陆成功。如果已经在其他的系统登陆了，则将请求转回 CAS Client，并且带回一个ticket, CAS Client再次发送请求到ValidateURL。否则，系统提示用户输入ID和PASSWORD。
