Java 多个实例上具有相同名称的多个客户端的CA

我们有两个应用程序（abc和def）是在Struts2中开发的，并与CAS server 3.2集成，用于SSO，部署在多个主机（IP）上。下面是部署架构图。SSO在以下部署中工作正常，没有问题

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

也许这是个愚蠢的问题，我也不知道。如何解决这个问题。任何人都可以在这方面帮助我。在以上两种情况下，URL相同或相同

更新：

从abc注销后，仍将登录到应用程序def

---

看起来你想在这里实现某种集群

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

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

棘手的会议

如何将流量从客户端（或CA）路由到 单个应用程序节点

负载平衡器

在所述负载平衡变体上 首先，应该注意，组成客户机应用程序集群的节点是2个还是4个并不重要。所描述的问题在任何情况下都应该发生。因为CAS服务器总是知道并只使用给定客户机应用程序的一个地址—指向负载平衡器的地址

问题出在哪里 如上所述，（会话关联性）用于负载平衡。而且，由于默认情况下CAS服务器使用所谓的“后通道”进行单次注销（SLO），因此它向给定的客户端应用程序本身发出（POST）注销请求，而不传递任何会话标识符（Java servlet命名为

JSESSIONID

的cookie）。因此，负载平衡器必须随机选择目标节点

如何解决这个问题 通常有两种可能的解决方案：

注意将“反向通道”注销请求传播到所有其他节点。这意味着CAS服务器或给定的应用程序需要知道所有其他节点的地址，并将请求传递给它们

使用所谓的“前通道”而不是“后通道”SLO。这意味着稍微修改（GET）的注销请求由用户的浏览器而不是CAS服务器完成。这意味着浏览器还会将应用程序会话标识符与请求一起传递，负载平衡器可以选择正确的节点进行会话失效。对于Apereo CAS，这是一个告诉CAS在相应的CAS服务/客户端应用程序配置中应使用前端通道的问题（参见其文档，例如），并在应用程序中使用兼容的

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

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

通过以下方式使用解决方案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

进一步阅读

在所述负载平衡变体上 首先，应该注意，组成客户机应用程序集群的节点是2个还是4个并不重要。所描述的问题在任何情况下都应该发生。因为CAS服务器总是知道并只使用给定客户机应用程序的一个地址—指向负载平衡器的地址

问题出在哪里 如上所述，（会话关联性）用于负载平衡。而且，由于默认情况下CAS服务器使用所谓的“后通道”进行单次注销（SLO），因此它向给定的客户端应用程序本身发出（POST）注销请求，而不传递任何会话标识符（Java servlet命名为

JSESSIONID

的cookie）。因此，负载平衡器必须随机选择目标节点

如何解决这个问题 通常有两种可能的解决方案：

注意将“反向通道”注销请求传播到所有其他节点。这意味着CAS服务器或给定的应用程序需要知道所有其他节点的地址，并将请求传递给它们

使用所谓的“前通道”而不是“后通道”SLO。这意味着稍微修改（GET）的注销请求由用户的浏览器而不是CAS服务器完成。这意味着浏览器还会将应用程序会话标识符与请求一起传递，负载平衡器可以选择正确的节点