1，
cas服务端值配置数据库验证，加密方式，返回数据等数据信息
cas客户端配配置认证请求，验证请求，包装请求，本地session，以及退出请求等请求
cookie(TGT的id,TIcket的id) ----session
一般的客户端，服务端的验证设计：
tooken-session
客户端：第一次传给服务端服务端自己生成的(token),第二次，传入sesion值，（token）值(传入服务器反写的，除token外)
服务端：第一次以K-V的方式组建（token）-session（发session个客户端）,存入缓存，第二次用客户端的此时传入的token作为key获取session
和传入的session比较，一致即通过验证，不一致或者为空即要求登录
cas的客户端验证：
cookie--session
cas服务端：登录成功后给客户端服务器，写session，自己留TGT(ticket)在缓存，浏览器写cookie（TgT的id）
客户端服务：获取浏览器的cookie信息，如果客户服务端session为空，cas服务器根据cookie能够获取ticket(TGT)即放行，同时生成session，
cookie在cas中获取不到对象就要求登录
客户服务端session不为空直接放行
也就是说K-V的匹配实现在cas服务器完成，不像传统的在web服务中完成，其他的比如session不为空即放行仍一致
客户端要实现登录要走完这些过滤器
整理一下整个登录流程（一次登录包含三次请求）：
第一次请求应用服务器：
当用户第一次访问应用服务器的URL，由于session中没有"_const_cas_assertion_"且参数中没有ticket（或cookie没有值，cookie有值可以生成session），会被AuthenticationFilter跳转到CAS服务器的登录页面。
第二次请求应用服务器：
在CAS服务器的登录页面成功登录以后，会跳转到应用服务器登录前的页面，但是加上了一个参数ticket。此次请求由于有ticket参数，通过了AuthenticationFilter，但是TicketValidationFilter会对ticket进行校验，校验成功后，会在session中加入"_const_cas_assertion_"，再去掉ticket参数进行一次跳转。
第三次请求应用服务器：
此时由于session中已经有了"_const_cas_assertion_"，会通过AuthenticationFilter，由于没有ticket参数，也通过了TicketValidationFilter，也就是可以正常显示出这个页面了。以后再请求应用服务器就和这次一样了，由于session包含"_const_cas_assertion_"即可正常访问。
http://zhenkm0507.iteye.com/blog/546805