cas单点登录源码

A. 终于搞明白了，CAS单点登录原理解析！！

真的如老话所说，“没有笨的人，只有懒得人”。前段时间时间需要和其他项目做cas集成，于是乎在网上找了几篇教程看了一下，好了，很简单，学会了，开搞（自以为研究明白）。集成完事了，登录成功了，自以为这就过去了。然而，没过几天就出bug了，这下惨了，当初没有好好学出了问题都不知道咋解决。无奈，只得静下心来好好学习一番（当初太懒付出的代价）。原理其实很简单的，只要耐下心来好好研究终会搞懂的。

先看下图

那么是如何验证用户是否登录过呢？

如果session中包含“ const_cas_assertion ”属性，说明已经登录，跳过此过滤器执行配置的其他过滤器；

如果ticket参数不为空（可能是登陆后跳转回来的），跳过此过滤器，执行TicketValidationFilter 验证ticket；

如果前两个条件都不满足，重定向到cas服务端，返回登录页面进行登录操作。

Cookie中的CASTGC：向cookie中添加该值的目的是当下次访问 www.cas.server.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生成的，默认是用一次就生效了。也就是上面的ticket值。

为了加深理解，也为了以后作参考，整理记录。另外，还要说一句，不要偷懒，多动手多动脑！

B. 单点登录cas 高手请进spring报错……

你的是耶鲁的那个cas吗，那个客户端与某些spring版本有冲突，我当初用spring1.2.6没问题，这个客户端还必须在能解析dns的机器上运行不然报连接超时，因为源码里面加密那段代码有访问耶鲁的网站

C. CAS搭建单点登录Web端

①前端vue项目判断如果有token,则说明用户已登录，可以访问客户端A的服务。否则未登陆，未登陆有两种状态：在单点登录服务端已经登录和未在单点登录服务端登陆

    判断如果有ticket，则说明已在单点登录服务端登录。调用/cas/client/validateLogin接口验证该ticket是否有效。转②

    判断如果无ticket,则说明未在单点登录服务端登录。则定向到单点登录服务端。转③

②/cas/client/validateLogin接口方法，发起http请求到单点登录服务端进行ticket验证，如果验证通过，则登录成功。单点登录客户端A生成token返回给前端，之后前端通过携带token访问客户端A的服务。

③单点登录服务端返回登录表单，用户输入用户名密码确定登录后，单点登录服务端调用用户信息验证端/auth/user/login接口，传递用户名密码参数，将验证委托给用户信息验证端

④登录成功验证通过后，携带ticket返回浏览器，重定向地址如下:

http://localhost:8000/?ticket=ST-6-NqvtyjRhezstXiyyzNNN-C-DiTw-DESKTOP-CVVQ0QK

接入用户信息验证端参考

D. 怎么导入cas单点登录源码进行编辑

SSO将一个企业内部所有域中的用户登录和用户帐号管理集中到一起，SSO的好处显而易见： 减少用户在不同系统中登录耗费的时间，减少用户登录出错的可能性 实现安全的同时避免了处理和保存多套系统用户的认证信息 减少了系统管理员增加、删除用户和...

E. CAS 中央认证服务 实现 单点登录（SSO）

CAS—认证原理

单点登录系统(SSO)之CAS(中央认证服务)

CAS中央认证系统

F. 【单点登录】CAS协议

CAS协议是专门为CAS开发的一种简单而强大的基于票据的协议。

CAS涉及到一个或多个客户端与一个服务端，客户端嵌入CASified应用程序(称为“CAS服务”)，而CAS服务器是一个独立组件:

1.CAS服务器负责对用户进行身份验证并授予对应用程序的访问权

2.CAS客户端保护CAS应用程序，并从CAS服务器检索被授予用户的标识。

关键概念：

1.存储在CASTGC cookie中的 TGT (票据授予票据)表示用户的一个SSO session。

2. ST (服务票证)作为url中的GET参数传输，表示由CAS服务器为特定用户授予认证应用程序的访问权限。

WEB流程：

1.用户访问目标应用程序，通过浏览器发送GET请求到目标应用

2.目标应用检测到用户未认证，则转发请求到CAS服务端，带上查询参数service，值为目标应用地址。

3.CAS服务端检测用户发现没有SSO session 则返回CAS登录页面。

4.用户在CAS登录页面填写登录表单，提交进行认证。

5.认证成功后CAS服务端创建SSO session,并创建TGT票据到Cookie中 （Set-Cookie:CASTGC=TGT-xxxxxx），并重定向到目标应用程序带上查询参数ticket=ST-xxxxx。

6.目标应用发送请求向CAS服务器验证ST票据，验证成功后目标应用创建用户访问session,并把sessionID放入cookie中。

7.用户访问目标应用通过sessionID获取到session,登陆成功。

8.用户访问其他CAS客户端应用，其他CAS客户端重定向请求到CAS服务器，同步骤2。

9.CAS服务器检测到用户TGT这个cookie,获取到SSO session，直接认证成功，并重定向到目标应用程序带上查询参数ticket=ST-xxxxx。

10.同步骤6，7，成功登陆其他CAS客户端应用。

G. CAS-5.3单点登录/退出客户端搭建(Springboot)

使用Springboot搭建cas客户端，主要是配置四个过滤器和一个监听器。

用于过滤不需要登录的用户，需要实现UrlPatternMatcherStrategy 接口，在matches 函数里添加不需要用户登录的链接。

按照同样的方法实现客户端系统2。
启动cas服务器端和两个客户端。输入 http://springbootcasclient.com:8001/ ，则跳转到登录界面

单点退出，需要下面三个步骤:1、添加过滤器类，过滤掉不需要登录的url；2、添加退出跳转的控制器；3、修改服务端application.properties ，加cas.logout.followServiceRedirects=true，让客户端可以自己制定退出的路径，否则会走默认退出路径。

过滤器类需要实现UrlPatternMatcherStrategy接口，然后配置到springboot中，请参考 单点登录 的 创建过滤器类 和 配置过滤器到springboot 。

退出的方式有两种，一种是走默认的路径，另一种是走自定义的返回路径。请参考 单点登录 的 用户退出控制器 。

将上面的内容添加到applicaiton.properties, 这样就可以允许客户端定制自己的退出路径了。

http协议配置：cas 5.3.x默认客户端不支持http协议, 如果不进行配置，则会出现“未认证授权的服务”错误。

要配置兼容http协议，需要在HTTPSandIMAPS-10000001.json文件中添加http。

H. CAS 单点登录原理解析

CAS是耶鲁大学发起的一个开源单点登录项目，也是用的最为广泛的开源项目。对于学习SSO有非常好的参考价值

单点登录（Single Sign On），简称为 SSO。多用于多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，最简单的单点登入实现可以完全基于 cookie ，通过往浏览器写带有登入信息的token来达到多点登入的目的，有兴趣的可以自己动手实现一个

先盗个图 ：

从结构上看，分成了三部分：CAS Client，CAS Server，浏览器

CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个Web请求

下面我将分为两部分（用户第一次登录验证和之后的登录验证）详细解析其登入原理

以上是第一次验证时基本流程

跨域的关键在于浏览器端的Cookie: TGC ，因为这个Cookie是设置在 SSO Server 端的，也就保证了统一票据和 Client 端域名无关。

cas 单点登录核心就是 单个cookie ， N个session

在该协议中，所有与 CAS Server 的交互均采用 SSL 协议，以确保 ST 和 TGC 的安全性。

I. CAS单点登录原理分析(一)

一，业务分析

在分布式系统架构中，假设把上述的三个子系统部署在三个不同的服务器上。前提是用户登录之后才能访问这些子系统。那么使用传统方式，可能会存在这样的问题：

1.当访问用户中心，需要用户登录帐号

2.当访问购物车，还需要用户登录帐号

3.当访问商品结算，又一次需要用户登录帐号

访问每一个子系统都需要用户登录帐号，这样的体验对于用户来说是极差。而使用单点登录就可以很好地解决上述的问题。

二，单点登录

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO 的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

我们目前的系统存在诸多子系统，而这些子系统是分别部署在不同的服务器中，那么使用传统方式的 session 是无法解决的，我们需要使用相关的单点登录技术来解决。

第一步 ：用户访问应用系统1。过滤器判断用户是否登录，没有登录，则重定向（302）到认证系统去进行认证操作。

第二步 ：重定向到认证系统，显示登录界面，用户输入用户名密码。认证系统将用户登录的信息记录到服务器的session中。

第三步 ：认证系统给浏览器发送一个特殊的凭证ticket，浏览器将凭证交给应用系统1，应用系统1则拿着浏览器交给他的凭证ticket去认证系统验证凭证ticket是否有效。凭证ticket若是有效，将用户信息保存到应用系统1的session中一份，并告知应用系统1，用户通过认证。

第四步 ：用户通过认证，浏览器与网站之间进行正常的访问。

第五步 ：当用户再次访问应用系统1，由于应用系统1的session中有用户信息，所以就不用经过认证系统认证，就可以直接访问应用系统1了。

第六步 ：当用户再去访问其他应用系统时，浏览器会带着凭证ticket过去，其他应用系统到认证系统验证凭证，凭证ticket若是有效，将用户信息保存到其他应用系统的session中一份，并告知其他应用系统，用户通过认证。

第七步 ：用户通过认证，浏览器与网站之间进行正常的访问。

第八步 ：当用户再次访问其他应用系统，由于其他应用系统的session中有用户信息，所以就不用经过认证系统认证，就可以直接访问其他应用系统了。

三、Yelu大学研发的CAS(Central Authentication Server)

1.什么是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 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。下图是 CAS 最基本的协议过程：

2.CAS的详细登录流程

该图主要描述

1.第一次访问http://shopping.xiaogui.com

2.在登录状态下第二次访问http://shopping.xiaogui.com

3.在登录状态下第一次访问http://pay.xiaogui.com

下面对图中序号代表的操作进行说明

当用户第一次访问http://shopping.xiaogui.com

序号1: 用户请求http://shopping.xiaogui.com，会经过AuthenticationFilter认证过滤器(在cas client 的web.xml中配置)

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

大概知道这个就行，CAS的具体实现会在以后的博客中写道

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

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

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

序号4:  认证系统cas.xiaogui.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过滤器，去认证系统CAS Server判断ticket是否有效

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

CAS Client 客户端  shopping.xiaogui.com  中web.xml的配置

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

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

序号10:  shopping.xiaogui.com客户端接收到cas-server的返回，知道了用户已经登录，ticket有效，告知浏览器可以进行访问。

至此，用户第一次访问流程结束。

当用户第二次访问http://shopping.xiaogui.com

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

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

当用户第一次访问http://pay.xiaogui.com

序号13:   用户向pay.xiaogui.com  CAS Client客户端发出请求

序号14:  ：pay.xiaogui.com接收到请求，发现第一次访问，于是给他一个重定向的地址，让他去找认证中心登录。

序号15: 浏览器根据上面响应的地址，发起重定向，因为之前访问过一次了，因此这次会携带上次返回的Cookie：TGC到认证中心。

序号16:  认证中心收到请求，发现TGC对应了一个TGT，于是用TGT签发一个ticket，并且返回给浏览器，让他重定向到pay.xiaogui.comCAS Client客户端。

序号17: 根据上面响应回来的地址，进行重定向到pay.xiaogui.comCAS Client客户端

序号18:  pay.xiaogui.comCAS Client客户端带着ticket去认证中心验证是否有效。

序号19:  认证成功，把用户信息保存到客户端的session中，并把客户端的SessionID设置在Cookie中。当用户下次访问pay.xiaogui.comCAS Client客户端，直接登录，无需验证。

序号20:  告知浏览器可以进行访问

CAS单点登录的原理分析大致就是上述的这些，至于CAS单点登录的具体实现，将在下篇博客中写道。

J. CAS搭建单点登录rest认证-APP端接入方案

     <!-- restful -->

        <dependency>

              <groupId>org.apereo.cas</groupId>

              <artifactId>cas-server-support-rest</artifactId>

              <version>${cas.version}</version>

     </dependency>

     # ticket过期设置

     cas.ticket.st.numberOfUses=1

     cas.ticket.st.timeToKillInSeconds=60

注：http://localhost:9527/auth/cas/client/validateLogin为被保护后台封装的接口，该接口主要有两个功能：①调用https://cas.ananops.com:8443/cas/p3/serviceValidate向单点登录服务端验证该ST的真实性。②ST确认真实后，生成ACCESS-TOKEN以及登录用户信息并返回给APP端，用户访问被保护后台的服务。

postman测试https接口需要配置：