CAS单点登录

什么是单点登录

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO 的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
我们目前系统存在诸多子系统，而这些子系统是分别部署在不同的服务器中，当用户在身份认证服务器上登录了一次以后，即可获得访问单点登录系统中其他联邦系统和应用软件的权限。

什么是CAS？

CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。

CAS 具有以下特点：

1. 开源的企业级单点登录解决方案。
2. CAS Server 为需要独立部署的 Web 应用。这个CAS框架已经提供
3. CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。

从结构上看，CAS 包含两个部分：

1. CAS Server 和 CAS Client。
2. CAS Server 需要独立部署，主要负责对用户的认证工作；
3. CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。

下图是 CAS 最基本的协议过程：

当用户第一次访问https://business-center.zhy.com

序号1:用户请求https://business-center.zhy.com，会经过AuthenticationFilter认证过滤器(在cas client 的web.xml中配置)

主要作用：判断是否登录，如果没有登录则重定向到认证中心。

序号2: AuthenticationFilter发现用户没有登录，则返回浏览器重定向地址。

重定向的地址就是认证服务器CAS Server的地址，后面的参数是我们请求的客户端地址，这个参数目的就是为了认证成功以后，根据这个参数的地址重定向回请求的客户端

序号3: 浏览器根据响应回来的重定向地址，向https://cas.zhy.com认证系统发出请求

序号4: 认证系统https://cas.zhy.com接收请求，响应登陆页面

序号5:：用户登陆页面输入用户名密码，提交请求

序号6:：CAS Server 认证服务器接收用户名和密码，就行验证，验证逻辑CAS Server 已经实现，并响应给浏览器信息
图中1，2部分表示序号5 输入的用户名，密码，以及发出的请求。当认证服务器验证通过之后，根据请求参数service的值，进行重定向，其实就是回到了请求的客户端，同时会携带一个ticket令牌参数。同时会在Cookie中设置一个TGC，该cookie是网站认证系统cas.xiaogui.com的cookie，只有访问这个网站才会携带这个cookie过去。

*****注意：这个携带TGC的Cookie是实现CAS单点登录的关键所在！

Cookie中的TGC：向cookie中添加该值的目的是当下次访问cas.xiaogui.com认证系统时，浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。
TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）
TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。
ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面数字3处的ticket值。

序号7: 客户端拿到请求中的ticket信息，也就是图中1的位置
然后经过一个ticket过滤器Cas20ProxyReceivingTicketValidationFilter，去认证系统CAS Server判断ticket是否有效

这个过滤器的主要工作就是校验客户端传过来的ticket是否有效

CAS Client 客户端 business-center.zhy.com 中web.xml的配置

序号8: 向CAS Server认证系统发出验证ticket的请求，也就是图中2的位置，然后执行ticket验证

序号9: 通过校验之后，把用户信息保存到客户端的session中，并把客户端的SessionID设置在Cookie中，同时告知客户端ticket有效。当用户再次访问该客户端，就可以根据Cookie 中的SessionID找到客户端的Session，获取用户信息，就不用再次进行验证了。也就是图中响应给浏览器的部分。

序号10: business-center.zhy.com客户端接收到cas-server的返回，知道了用户已经登录，ticket有效，告知浏览器可以进行访问。
至此，用户第一次访问流程结束。

当用户第二次访问https://business-center.zhy.com

序号11:当用户第二次访问，仍然会经过AuthenticationFilter过滤器，但与第一次访问不同的是此时客户端session中已经存在用户的信息，浏览器中的Cookie会根据SessionID找到Session，获取用户信息，所以不需要进行验证，可以直接访问。

序号12: 客户端告知浏览器可以进行访问。

当用户第一次访问https://opera-admin.zhy.com

序号13: 用户向opera-admin.zhy.com CAS Client客户端发出请求

序号14: ：opera-admin.zhy.com接收到请求，发现第一次访问，于是给他一个重定向的地址，让他去找认证中心登录。
序号15:浏览器根据上面响应的地址，发起重定向，因为之前访问过一次了，因此这次会携带上次返回的Cookie：TGC到认证中心。

序号16: 认证中心收到请求，发现TGC对应了一个TGT，于是用TGT签发一个ticket，并且返回给浏览器，让他重定向到opera-admin.zhy.com CAS Client客户端。
序号17:根据上面响应回来的地址，进行重定向到opera-admin.zhy.com CAS Client客户端

序号18: opera-admin.zhy.com CAS Client客户端带着ticket去认证中心验证是否有效。

序号19: 认证成功，把用户信息保存到客户端的session中，并把客户端的SessionID设置在Cookie中。当用户下次访问opera-admin.zhy.com CAS Client客户端，直接登录，无需验证。
序号20: 告知浏览器可以进行访问

cas过期时间

cas客户端和cas服务端都可以设置过期时间
这个过期时间的意思是，浏览器访问cas客户端，经过cas认证登录成功后的一系列操作后，可以正常访问cas客户端
当浏览器一段时间没有请求cas服务器资源，超过cas服务端设定的过期时间后再去访问cas客户端资源后，需要重新走上图cas流程

假设cas服务端设定的过期时间是2小时，cas客户端设置的过期时间是1小时
如果上次访问cas客户端与本次访问间隔在1小时之内，那么这次访问cas客户端能正常拿到数据
如果上次访问cas客户端与本次访问间隔大于1小时，那么这次访问cas客户端不能直接拿到数据，此时都会重定向到cas服务端认证，直接通过浏览器携带的TGC去cas服务器上查找TGT，此时有两种情况

1. 此时如果与上一次cas认证登录时间间隔在2小时之内，那么会通过TGT签发ST，接着会执行cas基本过程图的6、7、8、9、10
2. 此时如果与上一次cas认证登录时间间隔大于2小时，那么上一次的TGT会失效，接着会执行cas基本过程图的4、5、6、7、8、9、10，重新认证