CAS

原文地址：http://blog.csdn.net/javaloveiphone/article/details/52439613

一、背景介绍

单点登陆：Single Sign On,简称SSO，SSO使得在多个应用系统中，用户只须要登陆一次就能够访问全部相互信任的应用系统。

CAS框架：CAS（Central Authentication Service）是实现SSO单点登陆的框架。

二、盗一张学习CAS绝大多都看过的图以及执行部分分析

注：已分不清原创，此处就不给出地址了。

从结构上看，CAS包含两个部分：CAS Server 和CAS Client须要独立部署，主要负责对用户的认证工做；CAS 
Client负责处理对客户端受保护资源的访问请求，须要登陆时，重定向到CAS Server.图1是CAS最基本的协议过程：

CAS Client 与受保护的客户端应用部署在一块儿，以Filter方式保护 Web 应用的受保护资源，过滤从客户端过来的每个 Web 
请求，同时， CAS Client会分析HTTP 请求中是否包请求 Service Ticket( 上图中的 Ticket) 
，若是没有，则说明该用户是没有通过认证的，因而，CAS Client会重定向用户请求到CAS Server（ Step 2 ）。 Step 
3是用户认证过程，若是用户提供了正确的Credentials， CAS Server 会产生一个随机的 Service Ticket 
，而后，缓存该 Ticket ，而且重定向用户到CAS Client（附带刚才产生的Service Ticket）， Service 
Ticket 是不能够伪造的，最后， Step 5 和 Step6是 CAS Client 和 CAS 
Server之间完成了一个对用户的身份核实，用Ticket查到 Username ，由于 Ticket是 CAS Server 
产生的，所以，因此 CAS Server 的判断是毋庸置疑的。

该协议完成了一个很简单的任务，全部与CAS的交互均采用SSL协议，确保ST和TGC的安全性。协议工做过程会有2此重定向过程，可是CAS 
Client与CAS Server之间进行ticket验证的过程对于用户是透明的。

总结一下，以下：

访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。

定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。

用户认证：用户身份认证。

发放票据： SSO 服务器会产生一个随机的 Service Ticket 。

验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证经过后，容许客户端访问服务。

传输用户信息： SSO 服务器验证票据经过后，传输用户认证结果信息给客户端。

2、在云里雾里进一步搜索、探究

先给出此部份内容出处： 《SSO CAS单点系列》之 实现一个SSO认证服务器是这样的，如下标红部分为本身的疑问。

一、登陆信息传递

 
用户首次登陆时流程以下：

1)、用户浏览器访问系统A需登陆受限资源，此时进行登陆检查，发现未登陆，而后进行获取票据操做，发现没有票据。

2)、系统A发现该请求须要登陆，将请求重定向到认证中心，获取全局票据操做，没有，进行登陆。

3)、认证中心呈现登陆页面，用户登陆，登陆成功后，认证中心重定向请求到系统A，并附上认证经过令牌，此时认证中心同时生成了全局票据。

4)、此时再次进行登陆检查，发现未登陆，而后再次获取票据操做，此时能够得到票据(令牌)，系统A与认证中心通讯，验证令牌有效,证实用户已登陆。

5)、系统A将受限资源返给用户。

 
已登陆用户首次访问应用群中系统B时：

1)、浏览器访问另外一应用B需登陆受限资源，此时进行登陆检查，发现未登陆，而后进行获取票据操做，发现没有票据。

2)、系统B发现该请求须要登陆，将请求重定向到认证中心，获取全局票据操做，获取全局票据，能够得到，认证中心发现已经登陆。

3)、认证中心发放临时票据(令牌)，并携带该令牌重定向到系统B。

4)、此时再次进行登陆检查，发现未登陆，而后再次获取票据操做，此时能够得到票据(令牌)，系统B与认证中心通讯，验证令牌有效,证实用户已登陆。

5)、系统B将受限资源返回给客户端。

二、登陆状态判断

用户到认证中心登陆后，用户和认证中心之间创建起了会话，咱们把这个会话称为全局会话。当用户后续访问系统应用时，咱们不可能每次应用请求都到认证中心去断定是否登陆，这样效率很是低下，这也是单Web应用不须要考虑的。

咱们能够在系统应用和用户浏览器之间创建起局部会话，局部会话保持了客户端与该系统应用的登陆状态，局部会话依附于全局会话存在，全局会话消失，局部会话必须消失。

用户访问应用时，首先判断局部会话是否存在，如存在，即认为是登陆状态，无需再到认证中心去判断。如不存在，就重定向到认证中心判断全局会话是否存在，如存在，按1提到的方式通知该应用，该应用与客户端就创建起它们之间局部会话，下次请求该应用，就不去认证中心验证了。

三、登出

用户在一个系统登出了，访问其它子系统，也应该是登出状态。要想作到这一点，应用除结束本地局部会话外，还应该通知认证中心该用户登出。

认证中心接到登出通知，便可结束全局会话，同时须要通知全部已创建局部会话的子系统，将它们的局部会话销毁。这样，用户访问其它应用时，都显示已登出状态。

整个登出流程以下：

1)、客户端向应用A发送登出Logout请求。 
2)、应用A取消本地会话，同时通知认证中心，用户已登出。 
3)、应用A返回客户端登出请求。 
4)、认证中心通知全部用户登陆访问的应用，用户已登出。

3、拨开云雾见青天

一、对上面全部标红疑问一一解释

1)、问：系统A是如何发现该请求须要登陆重定向到认证中心的？ 
答：用户经过浏览器地址栏访问系统A，系统A(也能够称为CAS客户端)去Cookie中拿JSESSION，即在Cookie中维护的当前回话session的id，若是拿到了，说明用户已经登陆，若是未拿到，说明用户未登陆。

2)、问：系统A重定向到认证中心，发送了什么信息或者地址变成了什么？ 
答：假如系统A的地址为http://a:8080/，CAS认证中心的服务地址为http://cas.server:8080/，那么重点向先后地址变化为：http://a:8080/————>ttp://cas.server:8080/?service=http://a:8080/，由此可知，重点向到认证中心，认证中心拿到了当前访问客户端的地址。

3)、问：登陆成功后，认证中心重定向请求到系统A，认证经过令牌是如何附加发送给系统A的？ 
答：重定向以后的地址栏变成：http://a:8080/?ticket=ST-XXXX-XXX，将票据以ticket为参数名的方式经过地址栏发送给系统A

4)、问：系统A验证令牌，怎样操做证实用户登陆的？ 
答：系统A经过地址栏获取ticket的参数值ST票据，而后从后台将ST发送给CAS server认证中心验证，验证ST有效后，CAS server返回当前用户登陆的相关信息，系统A接收到返回的用户信息，并为该用户建立session会话，会话id由cookie维护，来证实其已登陆。

5)、问：登陆B系统，认证中心是如何判断用户已经登陆的？ 
答：在系统A登陆成功后，用户和认证中心之间创建起了全局会话，这个全局会话就是TGT(Ticket Granting Ticket)，TGT位于CAS服务器端，TGT并无放在Session中，也就是说，CAS全局会话的实现并无直接使用Session机制，而是利用了Cookie本身实现的，这个Cookie叫作TGC(Ticket Granting Cookie)，它存放了TGT的id,保存在用户浏览器上。 
相关内容分析能够查看：《SSO CAS单点系列》之 实操！轻松玩转SSO CAS就这么简单(相识篇)

用户发送登陆系统B的请求，首先会去Cookie中拿JSESSION，由于系统B并未登陆过，session会话还未建立，JSESSION的值是拿不到的，而后将请求重定向到CAS认证中心，CAS认证中心先去用户浏览器中拿TGC的值，也就是全局会话id，若是存在则表明用户在认证中心已经登陆，附带上认证令牌重定向到系统B。

上面登陆状态判断也是这个逻辑。

6)、问：登出的过程，各个系统对当前用户都作了什么？ 
答：认证中心清除当前用户的全局会话TGT，同时清掉cookie中TGT的id：TGC； 
而后是各个客户端系统，好比系统A、系统B，清除局部会话session，同时清掉cookie中session会话id：jsession

二、对系统A登陆流程图添加注释，查看