对于这个老话题，网上太多的资料，但是要让大家清楚地理解CAS还是不太容易，所以，读了一些文章，并做了一些摘录整理，方便新人理解。


对于CAS登录的过程，下面这段是讲得最清楚的。


登录应用A


主要原理：用户第一次访问一个CAS 服务的客户web 应用时（访问URL：http://192.168.7.90:8081/web1），部署在客户web 应用的cas AuthenticationFilter (web.xml里的一个Filter，如果对这个filter不清楚，建议网上先找来看看它长什么样)，会截获此请求，生成service 参数，然后redirect 到CAS 服务的login 接 口（这是web.xml里cas AuthenticationFilter的一个属性)，url 为https://cas:8443/cas/login?service=http%3A%2F%2F192.168.7.90%3A8081%2Fweb1%2F， 认证成功后，CAS 服务器会生成认证cookie（CASTGC = TGT-3-xa5S5hd1S1e9aZmusv...giVjV-sso-dev.dceast.cn），写入浏览器，同时将cookie 缓存到服务器本地，CAS 服务器还会根据service参数生成ticket, ticket会保存到服务器，也会加在url 后面，然后将请求redirect 回客户web 应用，url为http://192.168.7.90:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZuMwnbMvxpCBcNAIi6-20 。 这时客户端的AuthenticationFilter 看到ticket 参数后，会跳过，由其后面的 TicketValidationFilter 处理，TicketValidationFilter会利用httpclient 工具访问cas 服务 的/serviceValidate 接口, 将ticket 、service 都传到此接口，由此接口验证ticket的有效性，TicketValidationFilter 如果得到验证成功的消息，就会把用户信息写入web 应用的session 里。至此为 止，SSO 会话就建立起来了，以后用户在同一浏览器里访问此web 应用时，AuthenticationFilter 会在session 里读取到 用户信息，所以就不会去CAS 认证，如果在此浏览器里访问别的web 应用时，AuthenticationFilter在session 里读取不到 用户信息，会去CAS 的login 接口认证，但这时CAS 会读取到浏览器传来的cookie ，所以CAS 不会要求用户去登录页面登录，只是会根 据service 参数生成一个ticket ，然后再和web 应用做一个验证ticket 的交互而已。


再结合上面的文字描述，来理解下面的这张图，就容易多了。

spacer.gifwKiom1Yjn4rRwjZjAAFNvHfsu9Q317.jpg


登录应用B


用户经过CAS登录应用A后，再次登录应用B时，由于应用B的session中没有成功登录中的信息，浏览器会再次访问CAS Server，CAS Server接受到请求后会从cookie中拿到TGC信息，一旦验证无误，就会将用户导向应用B的页面，至此应用B访问成功。


安全


那么问题来了，会不会某一个***拿到这个TGC后可以随意模拟单点登录呢？答案是肯定的。


但问题也没有想像中的那么严重，因为web浏览器和CAS Server是通过https传输的，所以可以认为是传输安全的，那么***也就不可以轻易地拿到TGC信息了。


参考资料
http://minjiechenjava.iteye.com/blog/1480263

http://blog.chinaunix.net/uid-22816738-id-3525939.html

http://www.blogjava.net/security/archive/2006/04/26/SSO_CASProxy.html