cas流程进一步梳理

cas流程进一步梳理:

shrio集成cas认证这块交给cas:

 

认证过滤器是一直都会走的（每一个控制中的请求），只是认证后就不再进入cas了

即认证过滤器优先比对session和cookie，没有再进入cas做认证或反向生成session

 （正是由于这种特性，是的接入cas的系统，虽然用户名，密码不同，但是只要一个子系统有登录就有了cookie，session，其他的子系统不用再登陆（不需再输入其他系统的用户名密码））

 

ticket:（CAS 服务器还会根据service 参数生成ticket）(ST)

cas端的验证票据的是否真假，是否过期

生成这个之后写入session到web,后面登陆跳转到其他web，会先有cookie生成ticket（ST）,验证成功之后根据cas存入的用户信息（TGT）生成session写到新的web

之后直接cookie和session验证

 

验证：（ST）（相当于对cookie做一次真伪，和时效验证）

 验证ticket 。以ticket 为参数，去缓存里找ServiceTicketImpl 对象，如果能找到，且没有过期，且ServiceTicketImpl 对象对应的service

 属性和service 参数对应，则验证通过，验证通过后，请求转发至casServiceSuccessView （cas/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationSuccess.jsp ），

 验证不通过，则转发到failureView 。

验证通过直接cookie和web  session比对

签发：

ST（Service Ticket）(找到对应的session缓存就签发)

ST是CAS为用户签发的访问某一service的票据。用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。

用户向CAS发出获取ST的请求，如果用户的请求中包含cookie，则CAS会以此cookie值为key查询缓存中有无TGT，如果存在TGT，

则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。

 

 

TGT（Ticket Grangting Ticket）（缓存cookie和session对）

TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。

用户在CAS认证成功后，CAS生成cookie，写入浏览器，同时生成一个TGT对象，放入自己的缓存，TGT对象的ID就是cookie的值。当HTTP再次请求到来时，

如果传过来的有CAS生成的cookie，则CAS以此cookie值为key查询缓存中有无TGT ，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。

 

 

 

 

 

 

 

 

 

参看：

http://awaitdeng.iteye.com/blog/1536424