1. 总体方案

本方案的目的是搭建一个高可用，高可伸缩的中心认证服务。环境是CAS服务器是可任意扩展的，任意一个CAS服务节点均是等效的，CAS服务器的状态信息是集中存储的；CAS服务的客户端应用也是集群的环境，客户端应用服务器也是可任意扩展的，客户端应用的session状态信息是集中存储的，任意两个应用服务节点都是等效的；CAS服务器和客户端应用的状态信息集中存储在缓存服务器Memcached上。该方案具有以下特性。

l 只支持Tomcat6.x和Tomcat7.x。

l 无单点故障。

l 能够应对Tomcat故障转移。

l 能够应对memcached故障转移。

注意：上述方案中有一个问题是如果cas服务端应用程序或者客户端应用程序将某些状态数据直接存储在jvm本地对象中的时候，则节点会出现不等效的情况，甚至出现不稳定的故障。该问题的解决办法是：1.避免这样的情况。2.同步各jvm实例之间的所有对象。

1.1. 正常登录流程（未单点登录）讨论

讨论用户的浏览器里无TGT cookie值，即未曾登录过CAS服务器。

1. 用户浏览器访问必联网受保护的资源，假设用户未登录必联网应用，由于必联网各节点的session状态集中存储，则任意一个节点都是等效的。

2. 用户浏览器被转发请求到cas服务器。同时会带上参数service，即带上必联网的URL地址。

3. 用户访问cas服务的/login地址。用户的cookie中不存在TGT值。Cas服务器生成LT，并返回登录页面给用户浏览器。

4. 用户在登录页面上输入正确的用户名和密码，提交到cas服务器。

5. cas服务器接收到用户的凭证信息。经过验证后，若正确，则生成TGT，并存储在Ticket仓库中，由于带上了service参数值，同时cas会为该service生成ST值。然后返回到用户浏览器，将TGT值写入到用户浏览器的cookie中，同时将浏览器重定向都service参数值制定的url值，附带参数ticket=ST值。

6. 用户再次访问必联网受保护资源。带上参数值ticket=ST。必联网应用中的过滤器检测到带有该参数后，会将参数service和ticket的值发送请求给cas的URL地址/serviceValidate。该地址会校验ST。校验结束后会返回一个校验结果给客户端应用，如果正确则会返回登录的用户名。客户端应用则会在本应用为该用户执行登录后处理，如加载用户信息和权限等放入到session中。至此登录完成。

7. 考虑用户访问到不同的服务器上。如用户第一次访问到必联网应用节点1，第二次访问都必联网节点2上，由于session信息是共享的，则两个节点是等效的。若用户第一次访问到cas节点1，第二次访问cas节点2，由于session和票据信息是共享集中存储的，用户访问到任意节点都是等效的，票据在任意节点都能够得到有效地认证。

结论：该情况的流程集群不存在问题。

1.2. 已单点登录流程

当用户浏览器有合法的TGT，即用户浏览器已经登录过CAS服务器。在这种情况下，用户再访问必联网，用户未登录必联网应用。

1. 用户访问必联网受保护的资源，由于必联网各节点的session状态集中存储，则任意一个节点都是等效的。由于用户未登录必联网应用，则会拦截该请求，将其请求转发到CAS服务器，同时会带上参数service，即带上必联网的URL地址。

2. 用户访问cas服务的/login地址。由于已经登录过cas服务器，则用户的cookie中存在TGT值，在对该TGT值进行验证，若正确，由于带上了service参数值，同时cas会为该service生成ST值。然后返回到用户浏览器，同时将浏览器重定向都service参数值制定的url值，附带参数ticket=ST值。

3. 用户再次访问必联网受保护资源。带上参数值ticket=ST。必联网应用中的过滤器检测到带有该参数后，会将参数service和ticket的值发送请求给cas的URL地址/serviceValidate。该地址会校验ST。校验结束后会返回一个校验结果给客户端应用，如果正确则会返回登录的用户名。客户端应用则会在本应用为该用户执行登录后处理，如加载用户信息和权限等放入到session中。至此登录完成。

4. 考虑用户访问到不同的服务器上。如用户第一次访问到必联网应用节点1，第二次访问都必联网节点2上，由于session信息是共享的，则两个节点是等效的。若用户第一次访问到cas节点1，第二次访问cas节点2，由于session和票据信息是共享集中存储的，用户访问到任意节点都是等效的，票据在任意节点都能够得到有效地认证。

结论：该情况的流程集群不存在问题。