CAS的大致原理自不必说，在网络上是个很大的东西，但具体的对话流程不清楚，所以有这篇文章。 如果有错误的话，请多多关照
登录过程
当用户首次访问CAS服务客户web APP应用程序时(访问URL:http://192.168.1.9033608081/web1)，
部署在客户web APP应用程序中的CAS AuthenticationFilter将侦听此请求，生成service参数，并将其重定向到cas服务的登录接口。
url是https://cas:8443/cas/login？ service=http://192.168.1.90:8081/web1/logout URL=http://192.168.1.90:8081/web1/logout /
此URL有两个地址。 一个是登录完成后的跳转地址，另一个是用户注销时访问的当前服务的注销URL地址。 然后，该地址将存储在CAS服务器中，并在用户注销时使用
如果认证成功，CAS服务器将生成认证cookie并将其写入浏览器，同时在服务器本地缓存该cookie。
CAS服务器基于服务参数生成ticket。 ticket保存在服务器上，并添加在url之后。
然后将请求redirect返回给客户的web APP应用程序。 url为http://192.168.1.9033608081/web1/ticket=ST-5-sx6eyvj7CPP cfn0pmzumwnbmvxpcbcnaii6- 20。
在这种情况下，客户端的AuthenticationFilter会看到并跳过ticket参数，然后由后续的TicketValidationFilter处理。
TicketValidationFilter利用http客户端工具访问cas服务的/serviceValidate界面。
通过将ticket和service都传递给此接口，接口将验证ticket的有效性，如果TicketValidationFilter收到验证成功的消息，则为、
将用户信息写入web APP应用程序的会话。 这样就建立了SSO会话。 然后，当用户在同一浏览器中访问此web APP应用程序时，
AuthenticationFilter通过session读取用户信息，所以不去CAS认证。 如果在此浏览器中访问其他web APP，AuthenticationFilter将无法在session中读取用户信息。
我去CAS的登录界面进行认证，因为CAS会读取浏览器发送的cookie，所以CAS不会要求用户登录登录页面，而是根据service参数生成ticket。
然后，它与web APP应用程序进行验证ticket的交互。
注销过程
当CAS server收到注销请求时，它会检测用户的TCG Cookie并清除相应的session，同时找到使用此TGC sso登录的所有APP应用程序服务器URL并提交请求。 所有回调请求都包含参数logoutRequest，用于访问此注销URL。
所有收到请求的APP应用服务器(或CAS client )都会分析此参数以获取会话Id，并根据此Id获取会话，然后删除会话。 这样就实现了单点登录功能，用户无法在这个具体的APP界面上继续操作，只能重新登录。
注：以上内容是根据网络内容整理的。 如果侵犯了你的权益，请联系我
原文： http://www.cn blogs.com/huba oxi/p/4977058.html