还是那句话，不要对一些名词产生畏惧，CAS本质解决的还是session共享的问题，只是共享方式区别于域名间cookie共享。假设我们有app1.star.com，app2.moon.com，cas.sun.com，分别代表应用1，应用2和CAS认证中心。首次请求app1时，会检查本地会话id，这时肯定是木有的，所以会重定向到cas认证中心进行登录认证， 登录完成cas中心会颁发一个ticket票据(名字无所谓，主要是ticket要关联cas中心sessionId)，ticket都是一次性使用，可以直接丢redis，设置较短的有效期，防止ticket泄漏重复使用。此时cas系统已是登录状态的，cas有自己的sessionId，并且生成的ticket可以关联到sessionId。so，cas就可以重定向回app1请求路径，并附带请求参数ticket。app1检查本地会话id，还是未登录，但是有了一个ticket，于是拿ticket去redis获取sessionId（不一定是redis，和cas放ticket一致即可）。app1有了sessionId，就可以拿到有关sessionId的attrs信息，然后自己在本地生成一个cookie，重定向到请求路径即可，这时检查本地会话id已经登录，app1就完成了登录相关操作。
这时再请求app2，同样检查本地会话id，未登录跳转cas中心，但此时cas已经登录了，so，cas直接颁发一个ticket跳转回app2原请求url。app2检查本地会话id，还是未登录，但是有了一个ticket，于是拿ticket去redis获取sessionId及相关会话id数据，然后生成自己的cookie，跳转到请求路径，至此app2也完成了免登操作。
原理搞清楚了，宏观而言，实现起来自然非常简单，搞一套cas认证中心，然后外放一套cas认证依赖，搞定。