背景
前几天写过一篇博客Net单点登录详解
(SSO)，但是在这篇博客中是在asp.net 下做的实验，没有什么问题，但是转换到mvc中之后，问题就接二连三的出，后来没有办法，想想还是用人家已经写好的吧，别用那些自己写的东西了，一是不稳定，二是有很多的缺陷！然后就开始寻找！最后决定用cas来做！
SSO介绍
SSO英文全称SingleSign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
CAS = CentralAuthentication Service，中央认证服务。CAS(Central Authentication Service)是一款不错的针对 Web 应用的单点登录框架。
SSO的解决方案很多，比如收费的有UTrust、惠普灵动等，开源的有CAS、Smart SSO等，其中应用最为广泛的是CAS。
工作原理
CAS从结构上看包括两部分，CAS Server为需要独立部署的 Web 应用，CAS Client 为非常多的客户端提供支持，这个客户端指单点登录系统中的各个 Web 应用，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
CAS 原理和协议
CAS Server 需要独立部署，主要负责对用户的认证工作；
CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。图是 CAS 最基本的协议过程：
CAS Client 与受保护的客户端应用部署在一起，以Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket（服务票据，由 CAS Server发出用于标识目标服务）
如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。如果有，则说明当前用户已经登录，直接访问目的资源地址。
用户输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（CAS会话标识）
CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CASServer 进行身份合适，以确保 Service Ticket 的合法性。
在该协议中，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。