cas认证时出现的问题，怎么回事

网络问题或浏览器问题。

cas认证失败是网络问题或服务器错误，需要检查网络防火墙设置，从日志看应用服务器，不能访问cas服务器。需要开放cas服务器的端口给应用服务器，因此在认证时要注意选择合适的服务器。

另外在利用cas开发单点登录系统时，不应该使用跨域的跳转，如果因为服务器部署架构的问题，需要跨域也该考虑利用接口进行数据传递，因此在认证使用时要注意。

扩展资料：

CAS集群部署首先需要考虑的是ticket票据统一存储的问题，以便于达到每个节点访问的一致性，官方虽然提供了基于memcached方式，但未提供基于Redis方式，项目中需要使用redis。

因此仿照memcached方式，新建cas-server-integration-redis工程，来完成工作需求，开源的、多协议的SSO解决方案，有Protocols：CustomProtocol、CAS、OAuth等。

除此之外这个支持多种认证机制：ActiveDirectory、JAAS、JDBC、LDAP、X.509Certificates等；安全策略要使用票据（Ticket）来实现支持的认证协议。

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

现在我已经为站点整合了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超时结果图：

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

---