0

我们有两个应用程序（abc和def）是在 Struts2 中开发的，并与用于 SSO 的 CAS 服务器 3.2 集成，部署在多个主机 (IP) 上。该部署架构图如下。SSO 在以下部署中运行良好，没有问题。

在此处输入图像描述

我们在同一主机上部署了具有多个实例（具有端口8080和8081的 tomcat）的相同的两个 CAS 客户端（abc和def ）。请参阅下面的部署架构图。使用此 SSO 无法正常工作，单点登录工作正常，但是当用户从abc应用程序注销（其在 Host2 的 8081 端口上运行）时，会话过期请求将转到def应用程序（其在Host2的8080端口上运行）。使用此用户未从def应用程序（其在8081端口上运行）注销（会话未过期）主机2）。

在此处输入图像描述

可能这是我也不知道的愚蠢问题。如何解决这个问题。任何人都请帮助我。在上述两种情况下，URL 相同http://domain.in/abc/login.do或http://domain.in/def/login.do

更新：

从abc注销，仍然登录在应用程序def中。

看起来您正在尝试在这里实现某种集群？

是的。我想实现所有 CAS 客户端的单次注销。但在这里它没有发生。如上所述，注销命令正在发送到其他实例。

您是否在同一应用程序设置的节点之间进行会话复制？

粘性会话。

您如何将来自客户端（或来自 CAS）的流量路由到各个应用程序节点？

负载均衡器

4

1 回答 1

2

关于所描述的负载平衡变体

首先，应该注意的是，是否有 2 个或 4 个节点组成客户端应用程序集群并不重要。所描述的问题无论如何都应该发生。因为 CAS 服务器始终只知道并使用给定客户端应用程序的一个地址 - 指向负载平衡器的地址。

问题出在哪里

如上所述，粘性会话（会话亲和性）用于负载平衡。并且因为默认情况下 CAS 服务器使用所谓的“反向通道”进行单次注销 (SLO)，它会向给定的客户端应用程序本身发出 (POST) 注销请求，而不传递任何会话标识符JSESSIONID（由 Java servlet命名的 cookie ）。因此，负载均衡器必须随机选择目标节点。

如何解决问题

通常有两种可能的解决方案：

  1. 负责将“反向通道”注销请求传播到所有其他节点。这意味着 CAS 服务器或给定应用程序需要知道所有其他节点的地址 - 并将请求传递给它们。
  2. 使用所谓的“前通道”而不是“后通道”SLO。这意味着稍微修改的 (GET) 注销请求是由用户的浏览器而不是 CAS 服务器完成的。这意味着浏览器还将应用程序会话标识符与请求一起传递，并且负载均衡器这次可以选择正确的节点来使会话失效。使用 Apereo CAS，这就是告诉 CAS 应该在相应的 CAS 服务/客户端应用程序配置中使用前通道（参见他们的文档，例如6.1.x）并在应用程序中使用兼容的CAS 客户端。

OP 的选项

您使用的是相当旧的 CAS 版本 3.2 - “前通道” SLO 似乎没有在 3.x 系列中实现。因此，选项如下：

  1. 坚持使用 CAS 3.x 并尝试以某种方式实现解决方案 1。

  2. 通过以下方式使用解决方案 2：

a) 尝试将一些较晚的 CAS 版本（见下文）中的“前通道”SLO 合并到 CAS 3.x 中。

b) 升级到 CAS 4.x 并使用其“前通道”SLO，“版本 1”。在这个版本中，CAS 依赖于注销请求的同步链接——应用程序被一个一个调用，每个应用程序都必须将浏览器重定向回 CAS，因此 CAS 可以重定向到链中的另一个应用程序。

c) 升级到 CAS 5.x 或更高版本并使用其“前通道”SLO，“版本 2”。在这个版本中，CAS默认发出异步Ajax 注销请求，这应该会导致更快、更稳定的 SLO。

进一步阅读

于 2019-12-05T00:54:25.997 回答