CAS单点登录-关于服务器超时以及客户端超时的分析 (十)

CAS单点登录-关于服务器超时以及客户端超时的分析 (十),第1张

一般情况下,当用户登录一个站点后,如果长时间没有任何动作,当用户再次单击时,会被强制登出并跳转到登录页面,提醒用户重新登录。

现在我已经为站点整合了CAS,并且已经实现了单点登录以及单点注销,那么当用户使用过程中,发生了超时的情况,估计也是自动强行登出了吧,而且其他部署了CAS的站点也跟着自动登出。

上面的是猜想,那么实际情况到底是什么样的?

CAS-Client客户端超时时间其实就是项目session的有效时间,默认:30分钟,(springboot2.x)可修改配置:

验证方法:

a. 事前准备:

b. 验证动作:

2分钟后,我优先单击webApp1的网页,仿佛没有发生任何与超时相关的处理,依然可以正常访问所有页面。并没有强制跳转到登录页。我再单击webApp2的网页,也可以正常浏览。

又过了2分钟,我优先单击webApp2的网页,可以正常访问。再此单击webApp1,也可以正常访问。

c. 验证结果:

cas服务器超时主要指的是TGT(ticket granting ticket)超时,如果TGT时间到期,则需要进行重新登录。默认是2小时。这里单位是秒

验证方法:

a. 事前准备:

b. 验证动作:

3分钟后,CAS-Server应该已经超时了,这时我访问webApp1,可以正常访问。访问webApp2,也可以正常访问。

6分钟后,CAS-server与webApp1应该都超时了,这时访问webApp1,页面被强制重定向到登录页面了。再访问webApp2,发现仍然可以正常访问。

11分钟后,webApp2页超时了,这时访问webApp2,页面就被重定向到登录页面了。

c. 验证结果:

3.一个客户端超时并不会影响其他客户端的正常访问。

从上面两个验证可以发现,一旦客户端通过CAS-Server认证后,客户端就相当于完全独立了,即使再访问客户端的页面,客户端与CAS-Server之间也不会再发生任何交互或者验证动作。

一直到客户端强制退出或者超时后,才会主动发起认证请求,CAS-Server才会被动处理请求,判断是需要重定向还是重新认证通过。

也就是说,如果服务器超时时间设置的过短,并不会起作用,还是要等客户端超时才行。

鉴于以上结论,客户端和服务器的超时时间设置应该为:

CAS-Server(TGT)超时时间 >= CAS-Client的超时时间

从之前的验证来看,一个站点超时,并不影响其他站点的正常访问。

CAS-Server和CAS-Client超时结果图:

使用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。

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客户端应用。


欢迎分享,转载请注明来源:夏雨云

原文地址:https://www.xiayuyun.com/zonghe/315910.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-29
下一篇2023-04-29

发表评论

登录后才能评论

评论列表(0条)

    保存