CAS在多个实例上具有相同名称的多个客户端

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

CAS在多个实例上具有相同名称的多个客户端

我们已经部署了具有两个实例(端口为 8080 8081的tomcat)的相同的两个CAS客户端( abc def )。请参见下面的部署架构图。使用此SSO不能正常工作,但单点登录仍可以正常工作,但是当用户从 abc 应用程序(其运行在 Host2 8081 端口上)注销时然后会话过期请求将转到 def 应用程序(其运行在 Host2 8080 端口上)。使用此用户不会从 def 应用程序(其运行在 Host2 8081 端口上)注销(会话未过期)。

CAS在多个实例上具有相同名称的多个客户端

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

更新

abc 注销,仍保持在应用程序 def 中。

  

看起来您正在尝试在此处实现某种集群吗?

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

  

在同一节点之间是否有会话复制   应用程序设置?

粘性会议。

  

您如何将来自客户端(或来自CAS)的流量路由到   单个应用节点?

负载均衡器

yishan1987 回答:CAS在多个实例上具有相同名称的多个客户端

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

首先,应注意,由2个或4个节点组成客户端应用程序集群并不重要。所描述的问题在任何情况下均应发生。因为CAS服务器始终知道并仅使用给定客户端应用程序的一个地址-指向负载平衡器的地址。

问题出在哪里

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

如何解决问题

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

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

OP的选项

您使用的是非常老的CAS版本3.2-3.x系列中似乎未实现“前通道” SLO。因此,这些选项如下:

  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。

进一步阅读

本文链接:https://www.f2er.com/2987803.html

大家都在问