重定向session失效怎么解决_keycloak 集群配置 session 共享

前言

本文主要记录一下配置 keycloak 集群中 session 共享的过程。

问题出现

在之前的一篇博文 HAproxy 的 Sticky Session中曾经提到过用户的登录请求在多台 keycloak 之间跳来跳去的问题使用了 HAproxy 的 sticky session 解决了。

其实原理就是 HAproxy 在请求的 cookie 里面做了标记，当同一个客户端再次发起请求的时候，HAproxy 直接将请求路由到上一次接受请求的主机上，所以成功解决了登录问题。

但是，后面发现，这个貌似只适用于登录 keycloak 的管理界面，对于应用调用 keycloak 进行认证的流程（OAuth）并不适用。

应用跳转到 keycloak 获取认证之后重定向回来还是会出现不断跳，直到成功找到 token 为止。

分析问题

通过查看 HAproxy 的访问日志发现：

用户在浏览器输入用户名密码之后，点击登录，随即浏览器向 HAproxy 发起了一条登录请求。

HAproxy 将请求透传到后端某一台 keycloak 上，然后认证成功之后重定向到应用内部。

这个时候应用后台会带着 keycloak 的返回的 token 信息去请求 keycloak 校验 token，校验成功则认证成功，失败则认证失败。

就在这时问题出现了。

因为是应用后台发起的请求，所以并未带有相应的 cookie，所以此时会随机去到后端某一台 keycloak。

如果幸运正好路由到刚才接受认证请求的 keycloak 上，那么马上就认证成功，如果不幸运，那么就会出现请求失败。

然后由于设置了重试机制，那么会再次发起认证，然后再去校验 token。

这就出现了不断跳转或者说直观上的浏览器不断自动重新加载的情况了。

寻找出路

经过分析之后感觉 cookie 是解决不了问题了，继而转向了 session 共享的办法。

其实思路也很简单：

就是在任意一台机上面认证，整个集群马上就有相关的 token 信息。

那么无论访问哪一台 keycloak 获取 token 都是可以的，同时 HAproxy 也不再需要做任何配置。

解决办法

因为用的是 standalone-ha 方式搭建的集群，那么使用的 standalone-ha.xml 里面也已经有了共享 session 共享的配置。

使用的是 infinispan 分布式缓存来存储 session 信息。

这里只需要将 distribute 部分里面 owner 改成集群的节点数目即可，是为了防止挂掉部分机器之后丢失信息。

其次要重点关注的是配置 keycloak 集群通讯协议。

keycloak 默认使用的是 MPING 协议，也就是 Multicast PING。其实就是 udp 广播模式。但是在我们的环境里这做不了，因为做了很多防火墙规则。

那么就需要修改集群的通讯协议。

一开始使用的是 TCPPING 方式，但是后来发现 JDBC_PING 更为高效。

原因是使用 TCPPING 的话，每次集群扩容都必须更改每个节点的 server 列表并逐个重启，而 JDBC_PING 则是将集群成员信息记录在数据表，扩容只需要连接这个库就可以获取集群成员并通知所有节点。

至此，问题解决。

其实主要的是两点：一个是集群通讯协议，另一个就是缓存副本数。

参考

Chapter 7. List of Protocols​www.jgroups.org WildFly Clustering without Multicast​kb.novaordis.com