cas流程原理之一（及普通的验证原理比较）

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