单点登录springsecurity+cas

链接1 基础  参考价值大

http://dead-knight.iteye.com/blog/1525671   --Spring Security3源码分析-CAS支持

链接 2 http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html

         入门  参考价值很大(sso cas渊源,历史发展,技术发展,属于解释,为什么这样设计,等等)

CAS 是通过 TGT(Ticket Granting Ticket) 来获取 ST(Service Ticket) ，通过 ST 来访问服务，而 CAS 也有对应 TGT ， ST 的实体，而且他们在保护 TGT 的方法上虽然有所区别，但是，最终都可以实现这样一个目的——免去多次登录的麻烦。

--------------------------------

当 Step3 完成之后， CAS Server 会向 User 发送一个 Ticket granting cookie (TGC) 给 User 的浏览器，这个 Cookie 就类似 Kerberos(Kerberos  麻省理工学院开发的安全认证系统) 的 TGT ，下次当用户被 Helloservice2 重定向到 CAS Server 的时候， CAS Server 会主动 Get 到这个 TGC cookie ，然后做下面的事情：
1 如果 User 的持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果。
2 如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。

----------------------------

CAS Client 负责部署在客户端（注意，我是指 Web 应用）目前， CAS Client 支持（某些在完善中）非常多的客户端，包括 Java、.Net 、ISAPI、Php、Perl、uPortal、 Acegi、Ruby、VBScript 等客户端，几乎可以这样说， CAS 协议能够适合任何语言编写的客户端应用。

---------------------------

CAS 是通过 TGT(Ticket Granting Ticket) 来获取 ST(Service Ticket)

--------------------------

 SAML 是一种 SSO 标准而 CAS 是一种 SSO 的实现，从 CAS 的 Roadmap 可以看出， CAS 很快会提供对其他 SAML 的支持

------------------------

2.1.1 基础协议  2.2.2 CAS 的代理模式比较 :模式 1 已经能够满足大部分简单的 SSO 应用，现在，我们探讨一种更复杂的情况，即用户访问 helloservice ， helloservice 又依赖于 helloservice2 来获取一些信息.如同：
User à helloservice à helloservice2
这种情况下，假设 helloservice2 也是需要对 User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致 User 的 IE 窗口不停地 闪动 ) ， CAS 引入了一种 Proxy 认证机制，即 CAS Client 可以代理用户去访问其它 Web 应用。
代理的前提是需要 CAS Client 拥有用户的身份信息 ( 类似凭据 ) 。 与其说之前我们提到的 TGC 是用户持有对自己身份信息的一种凭据，则这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借 TGC ， User 可以免去输入密码以获取访问其它服务的 Service Ticket ，所以，这里，凭借 PGT ， Web 应用可以代理用户去实现后端的认证，而无需前端用户的参与。

备注：

1 下文中的链接四时序图(