多个实例上同名的多个客户端的 CAS
CAS for multiple clients of same name on multiple instances
我们有两个应用程序（abc 和 def）是在 Struts2 中开发的，并与 CAS 服务器 3.2 集成用于 SSO ，部署在多个主机（IP）上。该部署架构图如下。 SSO 在以下部署中运行良好，没有问题。
我们部署了相同的两个 CAS 客户端（abc 和 def）和多个实例（tomcat 端口 8080 和 8081) 在同一主机上。请参阅下面的部署架构图。使用此 SSO 在这里无法正常工作单点登录工作正常但是当用户从 abc 应用程序注销时（它的 运行 在 8081 端口Host2) 然后会话过期请求将转到 def 应用程序（它的 运行 在 8080 Host2 的端口）。使用此用户不会从 def 应用程序注销（会话未过期）（其 运行 在 8081 端口 Host2).
可能这是个我也不知道的愚蠢问题。如何解决这个问题。任何人都请帮助我。在以上两种情况下 URL 相同 http://domain.in/abc/login.do or http://domain.in/def/login.do
更新：
从 abc 注销，在应用程序 def 中保持登录状态。
Looks like you are trying to achieve some kind of cluster here?
是的。我想从所有 CAS 客户端实现单点注销。但这里没有发生。如上所述，注销命令正在发送到其他实例。
Do you have session replication among the nodes of the same
application setup?
粘性会话。
How do you route the traffic from clients (or from CAS) to the
individual app nodes?
负载均衡器
关于描述的负载平衡变体
首先，应该注意的是，是否有 2 个或 4 个节点构成客户端应用程序集群并不重要。描述的问题应该在任何情况下都会发生。因为 CAS 服务器始终只知道并使用给定客户端应用程序的一个地址 - 指向负载均衡器的地址。
哪里出了问题
如上所述，sticky sessions（会话关联）用于负载平衡。并且由于默认情况下 CAS 服务器使用所谓的 "back channel" 进行单点注销 (SLO)，它会向给定的客户端应用程序本身发出 (POST) 注销请求， 而不会传递任何会话标识符（由Java servlet 命名为JSESSIONID 的cookie）。因此，负载均衡器必须随机 select 目标节点。
如何解决问题
通常有两种可能的解决方案:
- 注意 "back channel" 注销请求传播到所有其他节点。这意味着 CAS 服务器或给定的应用程序需要知道所有其他节点的地址 - 并将请求传递给它们。
- 使用所谓的 "front channel" 而不是 "back channel" SLO。这意味着略微修改 (GET) 的注销请求是由用户的浏览器而不是 CAS 服务器完成的。这意味着浏览器还通过请求传递了应用程序会话标识符，并且负载均衡器这次可以 select 会话失效的正确节点。对于 Apereo CAS，这是告诉 CAS 应在相应的 CAS 服务/客户端应用程序配置中使用前端通道的问题（请参阅他们的文档，例如应用程序中的 6.1.x) and using a compatible CAS client。
OP 的选项
您使用的是非常旧的 CAS 3.2 版 - "front channel" 3.x 系列似乎没有实现 SLO。因此，选项如下：
坚持使用 CAS 3.x 并尝试以某种方式实施解决方案 1。
通过以下方式使用解决方案 2：
a) 尝试将 "front channel" SLO 从一些较新的 CAS 版本（见下文）合并到 CAS 3.x.
b) 升级到 CAS 4.x 并使用其 "front channel" SLO，"version 1"。在此版本中，CAS 依赖于注销请求的 同步 链接 - 应用程序被一个接一个地调用，每个应用程序都必须将浏览器重定向回 CAS，因此 CAS 可以重定向到另一个链上应用
c) 升级到 CAS 5.x 或更高版本并使用其 "front channel" SLO，"version 2"。在此版本中，CAS 默认进行 异步 Ajax 注销请求，这应该会导致更快、更稳定的 SLO。
进一步阅读
我们有两个应用程序（abc 和 def）是在 Struts2 中开发的，并与 CAS 服务器 3.2 集成用于 SSO ，部署在多个主机（IP）上。该部署架构图如下。 SSO 在以下部署中运行良好，没有问题。
我们部署了相同的两个 CAS 客户端（abc 和 def）和多个实例（tomcat 端口 8080 和 8081) 在同一主机上。请参阅下面的部署架构图。使用此 SSO 在这里无法正常工作单点登录工作正常但是当用户从 abc 应用程序注销时（它的 运行 在 8081 端口Host2) 然后会话过期请求将转到 def 应用程序（它的 运行 在 8080 Host2 的端口）。使用此用户不会从 def 应用程序注销（会话未过期）（其 运行 在 8081 端口 Host2).
可能这是个我也不知道的愚蠢问题。如何解决这个问题。任何人都请帮助我。在以上两种情况下 URL 相同 http://domain.in/abc/login.do or http://domain.in/def/login.do
更新：
从 abc 注销，在应用程序 def 中保持登录状态。
Looks like you are trying to achieve some kind of cluster here?
是的。我想从所有 CAS 客户端实现单点注销。但这里没有发生。如上所述，注销命令正在发送到其他实例。
Do you have session replication among the nodes of the same application setup?
粘性会话。
How do you route the traffic from clients (or from CAS) to the individual app nodes?
负载均衡器
关于描述的负载平衡变体
首先，应该注意的是，是否有 2 个或 4 个节点构成客户端应用程序集群并不重要。描述的问题应该在任何情况下都会发生。因为 CAS 服务器始终只知道并使用给定客户端应用程序的一个地址 - 指向负载均衡器的地址。
哪里出了问题
如上所述，sticky sessions（会话关联）用于负载平衡。并且由于默认情况下 CAS 服务器使用所谓的 "back channel" 进行单点注销 (SLO)，它会向给定的客户端应用程序本身发出 (POST) 注销请求， 而不会传递任何会话标识符（由Java servlet 命名为JSESSIONID 的cookie）。因此，负载均衡器必须随机 select 目标节点。
如何解决问题
通常有两种可能的解决方案:
- 注意 "back channel" 注销请求传播到所有其他节点。这意味着 CAS 服务器或给定的应用程序需要知道所有其他节点的地址 - 并将请求传递给它们。
- 使用所谓的 "front channel" 而不是 "back channel" SLO。这意味着略微修改 (GET) 的注销请求是由用户的浏览器而不是 CAS 服务器完成的。这意味着浏览器还通过请求传递了应用程序会话标识符，并且负载均衡器这次可以 select 会话失效的正确节点。对于 Apereo CAS，这是告诉 CAS 应在相应的 CAS 服务/客户端应用程序配置中使用前端通道的问题（请参阅他们的文档，例如应用程序中的 6.1.x) and using a compatible CAS client。
OP 的选项
您使用的是非常旧的 CAS 3.2 版 - "front channel" 3.x 系列似乎没有实现 SLO。因此，选项如下：
坚持使用 CAS 3.x 并尝试以某种方式实施解决方案 1。
通过以下方式使用解决方案 2：
a) 尝试将 "front channel" SLO 从一些较新的 CAS 版本（见下文）合并到 CAS 3.x.
b) 升级到 CAS 4.x 并使用其 "front channel" SLO，"version 1"。在此版本中，CAS 依赖于注销请求的 同步 链接 - 应用程序被一个接一个地调用，每个应用程序都必须将浏览器重定向回 CAS，因此 CAS 可以重定向到另一个链上应用
c) 升级到 CAS 5.x 或更高版本并使用其 "front channel" SLO，"version 2"。在此版本中，CAS 默认进行 异步 Ajax 注销请求，这应该会导致更快、更稳定的 SLO。