cas流程进一步梳理:
shrio集成cas认证这块交给cas:
认证过滤器是一直都会走的(每一个控制中的请求),只是认证后就不再进入cas了
即认证过滤器优先比对session和cookie,没有再进入cas做认证或反向生成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