CAS单点登录原理
例如阿里的淘宝，天猫，这是两个相互独立的模块。但是用户只拥有一个统一的账号，而不是让用户在每个分系统中进行账号的注册，然后分别登录，登出。上面所描述的就是单点登录的问题（SSO), 解决单点登录的方案有很多。但是每一种方案背后的原理及其相似；该篇博文主要讲了CAS 实现SSO;
学习一个新的东西，需要先了解这个东西是什么，他的原理是什么，然后在进行细节性的深入；
正文：
CAS 在体系结构上分为两类：CAS server 和 CAS client
CAS client在系统中担任处理客户端受保护资源的请求，及访问受保护资源时，会将请求重定向到cas server 进行认证。及通过FIlter进行保护受保护的资源，对于web发出请求访问受保护的资源时，cas client 分析该请求中是否包含ST(服务票据)，如果抱含，则允许访问受保护资源。
CAS Server 在应用中起到对用户认证的作用，在认证过程中，会为认证用户发放两个重要票据TGT(登录票据)，ST(服务票据)，这两个票据主导着整个CAS Server认证过程；
TGT(登录票据)
TGT是CAS Server为用户发放的登录票据，拥有该票据，说明该用户已经在CAS上成功登录过了。TGT里面主要封装了cookie以及cookie中对应的用户信息。用户在cas登录成功后，会生成一个TGT对象，放入缓存中，缓存的策略可以根据需求配置；同时cas 生成的cookie的信息会写在浏览器中，TGT 对象的Id 值就是cookie值，每次web 发来请求时，都会验证是否存在cas生成的cookie ,如果存在，cas 拿获取到tgt id进行查询TGT 是否存在，如果存在，说明用户之前已经登录过了，否则用户没有登录；如下图：
ST(服务票据)
ST是CAS Server 为用户发放的服务票据，用户登录每次请求去service(用户请求web地址)进行认证是否有ST，当Server发现用户没有ST时，请求转发至CAS 进行获取ST, 用户向CAS 发出获取ST 的请求，CAS 判断用户的请求中是否包含cookie,如果包含，则以cookie的值为key去缓存中查找TGT是否存在，如果查询到TGT,则为用户发放一个ST，用户凭借拥有的ST去Server进行验证，验证通过，允许用户访问相应资源；
ST是随机生成的，没有规律性，且CAS协议规定，ST只能使用一次，无论验证是否成功，Cas Server服务端都会销毁并清除缓存中的Ticket，从而保证ST不被使用两次,目的就是为了保证ST的安全，并且，ST还具有一定的时效性，及只能存活一段时间，然后CAS Server 会将他失效；
认证过程如下：
1，用户发出请求，访问系统B,首先会被AuthenticationFilter拦截该请求，首先判断请求中是否有cookie缓存用户信息，验证请求中是否有ST(服务票据)，发现两者都不存在是，将请求重定向到CAS Server，并携带需要访问目的资源的地址参数信息，以便验证成功后跳转到目的地址；及http://cas:8080/cas/login?service=http:xxxx;
2,请求重定向到CAS-Server后，用户输入用户名，密码登录，登录成功，CAS Server 生成登录票据，并随机生成ST，及Ticket,然后Cas-server会将ticket 添加到url 后边；
3，4，CAS Server将ticket添加到url后边后，然后将请求重定向到Web应用中，这是拦截器获取到请求后，获取ticket后，将ticket 通过httpClient工具，将ticket 和访问资源地址都传递到CentralAuthenticationService进行验证ticket的有效性，验证成功后，通知拦截器，拦截器获取到验证成功的信息后，将用户信息写到web 应用的session中；到此一个SSO建立完毕
5，验证成功后，web返回给用户访问允许访问的资源信息