一般一家企业内部会有多个业务系统，多个系统相互协作，但每个系统都需要登陆密码，比如：权限系统，发布系统，配置系统，邮件系统等，用户使用每个系统都需要登陆操作，使用起来比较繁琐，工作效率低下。此时就需要引入SSO来解决以上问题，把多个系统的登陆认证步骤集中在登陆系统统一管理，用户只需要登陆一次就可以在多个系统之间来回切换使用；目前实现SSO的主流框架就是CAS
基于Cookie
将用户名密码加密之后存于Cookie中，之后访问网站时在过滤器（filter）中校验用户权限，从Cookie中取出用户名密码进行登录，让用户从某种意义上觉得只登录了一次
统一认证中心方案原理
第一次访问www.qiandu.com
-
标号1 用户访问http://www.qiandu.com,经过他的第一个过滤器（cas提供，在web.xml中配置）AuthenticationFilter,判断是否登录，如果没有登录则重定向到认证中心
-
标号2 www.qiandu.com发现用户没有登录，则返回浏览器重定向地址;返回状态码302，然后让浏览器重定向到cas.qiandu.com并且通过get的方式添加参数service，该参数目的是登录成功之后会要重定向回来，因此需要该参数。并且你会发现，其实server的值就是编码之后的我们请求www.qiandu.com的地址
-
标号3 浏览器接收到重定向之后发起重定向，请求cas.qiandu.com
-
标号4 认证中心cas.qiandu.com接收到登录请求，返回登陆页面
-
标号5 用户在cas.qiandu.com的login页面输入用户名密码，提交
-
标号6 服务器接收到用户名密码，则验证是否有效，验证逻辑可以使用cas-server提供现成的，也可以自己实现
-
标号7 浏览器从cas.qiandu.com那里拿到ticket之后，就根据指示重定向到www.qiandu.com，请求的url就是上面返回的url
-
标号8 www.qiandu.com在过滤器中会取到ticket的值，然后通过http方式调用cas.qiandu.com验证该ticket是否是有效的
-
标号9 cas.qiandu.com接收到ticket之后，验证，验证通过返回结果告诉www.qiandu.com该ticket有效
-
标号10 www.qiandu.com接收到cas-server的返回，知道了用户合法，展示相关资源到用户浏览器上
第二次访问
-
标号11 用户发起请求，访问www.qiandu.com。会经过cas-client，也就是过滤器，因为第一次访问成功之后www.qiandu.com中会在session中记录用户信息，因此这里直接就通过了，不用验证了
-
标号12 用户通过权限验证，浏览器返回正常资源
访问mail.qiandu.com
-
标号13 用户在www.qiandu.com正常上网，突然想访问mail.qiandu.com，于是发起访问mail.qiandu.com的请求
-
标号14 mail.qiandu.com接收到请求，发现第一次访问，于是给他一个重定向的地址，让他去找认证中心登录;用户请求mail.qiandu.com，然后返回给他一个网址，状态302重定向，service参数就是回来的地址
-
标号15 浏览器根据14返回的地址，发起重定向，因为之前访问过一次了，因此这次会携带上次返回的Cookie：TGC到认证中心
-
标号16 认证中心收到请求，发现TGC对应了一个TGT，于是用TGT签发一个ST(ticket)，并且返回给浏览器，让他重定向到mail.qiandu.com
-
标号17 浏览器根据16返回的网址发起重定向
-
标号18 mail.qiandu.com获取ticket去认证中心验证是否有效
-
标号19 认证成功，返回在mail.qiandu.com的session中设置登录状态，下次就直接登录
-
标号20 认证成功之后就反正用想要访问的资源了