结构设定:
假设当前的系统结构为：A系统是cas server（cas.com), 两个客户系统B(b.com)和C（c.com)。
第一步，登录B系统：
当用户先访问B系统时，此时尚未登录，完整的处理流程如下：
核心阶段一：尝试访问，被拦截重定向
用户请求资源：用户在浏览器访问B系统的受保护页面
https://b.com/profile。B系统未登录检测：B系统检查用户的
Session或Cookie，发现没有登录凭证。B系统告知CAS地址：B系统构造一个CAS登录地址，生成一个Service参数（即登录成功后想让CAS把用户送回哪里去）。这个地址通常是
https://b.com/cas-callback。重定向至CAS：B系统通过302重定向，将用户浏览器引导至CAS服务器：
请求示例：
Location: https://cas.com/login?service=https://b.com/cas-callback
核心阶段二：统一认证 (在CAS Server)
CAS检查全局登录状态：CAS检查浏览器带来的Cookie中，是否有自己的全局票据（通常叫TGC，Ticket Granting Cookie）。
进入登录页：
如果是首次访问，没有TGC，CAS返回登录页面，用户输入用户名和密码。
CAS创建全局会话：
CAS验证用户凭证（如查数据库、LDAP等）。
验证成功后，CAS创建TGT（Ticket Granting Ticket，存于服务端），并生成TGC（存于客户端浏览器Cookie）。
此时，全局单点登录会话已建立，用户之后再访问C系统时，就不会再看到登录页了。
核心阶段三：派发票据，返回B系统
CAS生成服务票据：CAS生成一个一次性有效的服务票据（ST，Service Ticket）。这个ST与用户的身份，以及B系统提供的
service参数（https://b.com/cas-callback）是绑定在一起的。重定向回B系统：CAS将浏览器重定向回B系统最开始指定的那个地址，并附上
ticket参数。请求示例：
Location: https://b.com/cas-callback?ticket=ST-123456-abcde
核心阶段四：B系统后台校验，建立局部会话
B系统接收票据：浏览器带着ST票据，访问B系统的回调接口
https://b.com/cas-callback?ticket=ST-123456-abcde。B系统后台校验（关键环节）：
B系统在后台（用户不可见）发起一个HTTP请求给CAS服务器：
https://cas.com/serviceValidate?service=https://b.com/cas-callback&ticket=ST-123456-abcde。这是一个后台到后台的调用，通常也称为
CAS Client向CAS Server的验证（validation）。
CAS确认票据有效：
CAS验证
ST确实是它刚刚签发的、没有过期、并且service地址也匹配。验证通过后，CAS返回用户的登录名及相关属性给B系统的后台。
B系统创建局部会话：
B系统收到CAS返回的用户名（比如
user123）。B系统在自己的服务器端创建一个Session（局部会话），并在浏览器中写入B系统的Cookie（如
JSESSIONID）。用户正式登录B系统。
核心阶段五：完成访问
响应页面：B系统的回调接口处理完后，将页面重定向回用户最初想访问的地址
https://b.com/profile（或者直接展示首页）。展示内容：浏览器展示B系统内的页面给用户。
时序图：
第二步，登录C系统：
由于前一步，用户已通过登录B系统完成了认证，登录C流程则大幅简化：
用户访问C系统，C系统发现未登录 -> 重定向到
cas.com/login?service=c.com/callback。CAS检查浏览器，发现它早就带着步骤7中写入的TGC，所以不再提示登录。
立即生成ST，重定向回C系统的回调地址。
C系统后台拿着ST去CAS换用户信息。
C系统创建自己的Session，用户直接登录C系统。
