cas单点登录流程揭密

news2024/11/13 15:54:36

前言

前几篇文章，经过大篇幅讲解了cas整合以及Cookie和Session。
springboot+vue集成cas单点登录最详细避坑版讲解
关于cookie和session的直观讲解（一）
关于cookie和session的直观讲解（二）
那么，接下来，我们就结合起来一起实战看看。

cas基础原理

在这里插入图片描述
就这几步。

下边令牌的概念，记住这几个东西的作用。

TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）
TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。
ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就失效了。也就是上面数字3处的ticket值。

实操

准备条件

一个前端页面，作用是最后经过一系列的操作，定向到这个页面，并显示用户名；
一个springboot整合cas客户端的后端；
cas服务端，用tomcat启动。

未登录，第一次请求

请求详细图：

不着急研究，先看完下边再回来看。在这里插入图片描述

三角图第一、二、三步，请求被重定向到cas登录

首先我们访问后端接口：http://192.168.2.189:8010/lsdb-api/redirectToFrontend

看看浏览器做了什么？

访问这个接口，一定是被cas拦截器拦截并且验证的，没有登录，那就重定向到cas服务端登录，输入账号密码之后，认证成功。

可以看到，登录成功了，确实响应了一个TGC令牌，而且cas这个Cookie的path设置的是/cas/，也就是说，只有访问这个地址（cas服务端）才会携带这个Cookie。
此时，你的浏览器已经有了这个TGC令牌的Cookie。
为了模拟，我们可以将后端改个端口，再用jar启动一份，这样在我们访问这个新的后端端口是，这个后端是没有Session的，所以，一定会去cas服务端认证，为什么不跳转登录页面，因为Cookie中有TGC。

当cas客户端拦截器将请求重定向到/cas/login时，浏览器发现path含有/cas/，于是就将TGC这个Cookie也带上了，这样服务端直接拿这个TGC去校验。

发现TGC有对应的TGT，就继续下边的步骤通过了。
三角图第四、五步，重定向请求后端地址并验证ticket

这里可以看出，cas服务端重定向到上个图响应的Location地址，也就是携带ticket的地址，同时cas客户端响应了一个JSESSIONID，说白了就是在获取Session的时候设置的一个Cookie，就相当于Sessionid，通过它能找到Session，这个Session里保存有用户登录状态，而且path设置的是/，这就意味着本次浏览器会话都会携带。
可能有人说，我怎么没看见第五步去cas验证票据的访问，前边的请求图上确实没显示请求cas的地址，这是因为验证是cas客户端直接拿到ticket去访问cas服务端接口，验证结果是通过接口返回，并不是重定向，跟浏览器没关系，所以浏览器上并不会显示，验证也很简单，只需要把下边的cas验证地址改错，就能发现后端报错。
三角图第六步，cas服务端返回用户信息给cas客户端
通过上边一个图可以看出，验证通过之后，响应了一个带jsessionid的地址，那么，这里自然也会重定向到这个地址，当访问这个地址的时候，因为携带了jsessionid，那么就会cas客户端就会通过jsessionid获取到Session，从而获得登陆状态，直接正常请求接口，执行接口逻辑即可。

可以看到，终于是正常请求我们自己写的接口，并且重定向到8081的前端页面。

登录之后，第二次请求

第二次登录就简单多了，因为已经登陆了，我们在访问cas客户端或者前端地址都会携带Cookie，这样，后端通过Cookie就能获取到Session，这样就直接代表已登录，直接访问了。
在这里插入图片描述
Cookie的值JSESSIONID都是一样的，这样，我们就能把前边了解的session和cookie知识串联起来，在实际上看到作用和效果了。