单点登录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 下文中的链接四时序图(http://www.open-open.com/lib/view/open1432381488005.html)应该属于基础协议。

2 http://www.imooc.com/article/3720 到目前为止，其CAS认证协议已经持续发展了三个版本，v1实现了单点登录，此版本跟Nebula实现的功能差不多。
v2版则重点增加了proxy模式，代理模式是一种更复杂形式的认证，即认证的Web应用(CAS Client)可以作为代理直接访问需要认证的后端服务(如邮件服务器)，浏览器用户无需再和后端服务直接进行认证交互。这个比较复杂，在门户中可能会用到，我们这里不做讨论。
v3版本则更加丰富了协议，认证中心验证票据后不仅可以返回身份ID，还可携带用户昵称、性别等其他用户基本信息。
链接：http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html

链接 3 部分参考 ，重点看属于归纳和a依赖b，b依赖c，c需要登录这种情况

CAS 的 SSO 实现方式可简化理解为： 1 个 Cookie 和 N 个 Session 。 CAS Server 创建 cookie，在所有CAS Client应用认证时使用，各CAS Client应用通过创建各自的 Session 来标识用户是否已登录。

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

Step 3 是用户认证过程，如果用户提供了正确的 Credentials ， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，并且重定向用户到 Service 所在地址（附带刚才产生的 Service Ticket ） , 并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ）

原文链接：http://www.open-open.com/lib/view/open1432381488005.html --此篇其实写的不太清晰

链接4  部分参考 仅供参考（时序图见下文中图），介绍的不错，简单易懂

登录状态判断 http://www.imooc.com/article/3558
用户到认证中心登录后，用户和认证中心之间建立起了会话，我们把这个会话称为全局会话。当用户后续访问系统应用时，我们不可能每次应用请求都到认证中心去判定是否登录，这样效率非常低下，这也是单Web应用不需要考虑的。
我们可以在系统应用和用户浏览器之间建立起局部会话，局部会话保持了客户端与该系统应用的登录状态，局部会话依附于全局会话存在，全局会话消失，局部会话必须消失。
用户访问应用时，首先判断局部会话是否存在，如存在，即认为是登录状态，无需再到认证中心去判断。如不存在，就重定向到认证中心判断全局会话是否存在，如存在，按1提到的方式通知该应用，该应用与客户端就建立起它们之间局部会话，下次请求该应用，就不去认证中心验证了。。

这段话翻译：
一 
     无session，重定向到CAS Server 然后分两种情况，
        1， 如果 User 的持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果。
        2， 如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。 。  图中是无TGT 或 TGT 错误，我的理解是TGT和TGC类似 可以参考链接2里内容
二
   有session，登录状态。 

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

5)、问：：登录B系统，认证中心是如何判断用户已经登录的？ http://blog.csdn.net/javaloveiphone/article/details/52439613 --写的不错
答：在系统A登录成功后，用户和认证中心之间建立起了全局会话，这个全局会话就是TGT(Ticket Granting Ticket)，TGT位于CAS服务器端，TGT并没有放在Session中，也就是说，CAS全局会话的实现并没有直接使用Session机制，而是利用了Cookie自己实现的，这个Cookie叫做TGC(Ticket Granting Cookie)，它存放了TGT的id,保存在用户浏览器上。

为了理解"登录B系统，认证中心是如何判断用户已经登录的"里的提问：

结合链接3(http://www.open-open.com/lib/view/open1432381488005.html)的时序图

---------------------------时序图----------------------------------

此时序图如果要归类的话属于链接2 http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html 里的2.1.1 基础协议 不是2.2.2代理模式。

结合本连接(链接4)引用的源文章(http://www.imooc.com/article/3564)里的一段代码看到了本地会话的建立过程。

Auth auth = new Auth(); 
auth.setUserId(verifyResult.getUserId()); 
auth.setUsername(verifyResult.getUsername()); 
auth.setGlobalId(verifyResult.getGlobalId());
 request.getSession().setAttribute("auth", auth); 
//建立本地会话 return "redirect:http://" + returnURL; 

时序图里 第一步 判断是否有session  第六步 创建session ，这两步里的session对应这上面一段代码( request.getSession().setAttribute("auth", auth);)，

这个session里包含全局GlobalId。

个人理解总结，仅供自己参考：

这里面有两种会话1 用户和认证中心(client server)之间建立起的全局会话 2 用户和 client 客户端的本地会话。全局会话和本地会话都包含GlobalId。浏览器会保存两个cookie/session：和client 客户端的session ，和client的cookie(TGT)

全局会话怎么建立：在时序图第三步。http://www.open-open.com/lib/view/open1432381488005.html

        Step3是用户认证过程，如果用户提供了正确的 Credentials ， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证, 并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC），并且重定向用户到 Service 所在地址(地址指cas client客户端地址)并附带刚才产生的 Service Ticket (Ticket  用于cas client客户端向cas client server验证使用) 。在系统A登录成功后，用户和认证中心之间建立起了全局会话，这个全局会话就是TGT(Ticket Granting Ticket)，TGT位于CAS服务器端，TGT并没有放 在Session中，也就是说，CAS全局会话的实现并没有直接使用Session机制，而是利用了Cookie自己实现的，这个Cookie叫做TGC(Ticket Granting Cookie)，它存放了TGT的id,保存在用户浏览器上。--这个讲的不太好，部分参考吧。

本地会话：在第六步建立。具体建立过程见上文分析。

链接五

这篇图文详解博客里的TGT和session介绍的更清楚，有点像从零开始仿照sso用自己的代码写/实现sso，学这个可以更深入理解sso。时序图画的更容易入门http://www.imooc.com/article/3720

最全的时序图,有此时序图其他的时序图就不用看了。:http://elim.iteye.com/blog/2128728 当然这个时序图其实是来自官网。

附录：

单点登录的原理理解了,下一步就是集成springsecurity+cas

可以参考 代码链接1  http://tonyaction.blog.51cto.com/227462/898173  代码链接2  https://github.com/freehuoshan/authority 

这里介绍下单点登录验证通过后,授权的问题。假如验证通过在何处对通过的用户授权:认证的处理者是CasAuthenticationProvider(

原理见代码链接3 http://elim.iteye.com/blog/2270446)

CasAuthenticationProvider首先会利用TicketValidator（Cas概念）对Authentication中包含的ticket信息进行认证。认证通过后将利用持有的AuthenticationUserDetailsService根据认证通过后回传的Assertion对象中拥有的username加载用户对应的UserDetails。AuthenticationUserDetailsService通过userDetailsService从数据库中根据用户名查出对应的权限。

假如以见代码链接3这篇博客代码作为示例：http://elim.iteye.com/blog/2270446

Cas Server认证成功后的跳转地址，这里要跳转到我们的Spring Security应用，之后会由CasAuthenticationFilter处理，默认处理地址为/j_spring_cas_security_check 

Spring Security应用整合Cas使用Cas Proxy作为被代理端(意味着也可以作代理端)时主要需要进行三点修改...

(http://www.cnblogs.com/vhua/p/cas_5.html CAS 基本流程图（没有使用PROXY代理），使用代理的 CAS 流程图。
http://elim.iteye.com/blog/2270446 整合Cas。里面有使用代理模式。)

我们关心的是CasAuthenticationFilter-->AuthenticationManager-->CasAuthenticationProvider--authenticationUserDetailsService-->UserDetailsByNameServiceWrapper-->userDetailsService-->JdbcDaoImpl流程。JdbcDaoImpl也可以用自定义的实现类代替。

这里以CasAuthenticationProvider的authenticateNow方法作为入口跟踪(图片看不清可另存为查看)

Spring Security（20）——整合Cas:http://elim.iteye.com/blog/2270446  --haohaoxuexi

http://www.cnblogs.com/vhua/p/cas_5.html CAS 基本流程图（没有使用PROXY代理），使用代理的 CAS 流程图。
http://elim.iteye.com/blog/2270446 整合Cas。里面有使用代理模式。

http://elim.iteye.com/blog/2145751

cas server:http://www.iteye.com/blogs/subjects/cas168

cas server

cas 服务端的一些链接  
Cas的客户端(cas+springsecurity)和服务端结合的代码都有--(偏代码必看,可以此为蓝本搭建项目)  
https://github.com/freehuoshan  
cas server 配置介绍，偏理论介绍   
http://www.iteye.com/blogs/subjects/cas168  
cas 客户端和服务端源码解析 偏源码  
http://blog.csdn.net/dovejing/article/category/3013985  

https://github.com/freehuoshan/authority --集成 CAS 单点登录,单点登录与权限控制插件化
https://github.com/sgq0085/learn --learn-cas-clientlearn-cas-server Shiro通过Redis管理会话实现集群

https://github.com/ameizi/cas-server-webapp

http://www.cnblogs.com/leefreeman/archive/2012/11/13/2767644.html --CAS扩展——自定义查询数据库验证Handler

http://www.cnblogs.com/leefreeman/archive/2012/12/05/2802556.html --CAS扩展——自定义加密算法

http://sgq0085.iteye.com/blog/2099196 --cas server 4.0深度研究

源码解析结合第一个链接看，入口在login-webflow.xml，源码解析里从var name="credentials", 开始，对应着第一个链接的var name="credential"  

###springsecurity+cas代码可以部分借鉴：点击打开链接  问题：去获取访问当前资源url需要哪些权限role_xx。容器启动时会操作一次，如果后来管理员重新授权，访问当前url对应的需要的权限变了怎么办。即系统会在初始化时一次将所有资源加载到内存中，即使在数据库中修改了资源信息，系统也不会再次去从数据库中读取资源信息。这就造成了每次修改完数据库后，都需要重启系统才能时资源配置生效。我们只要想办法在管理员修改数据后，更新内存中数据map即可。参见我上一篇博客：http://mp.csdn.net/postedit/52203032