Red Hat 于 2026 年 10 月 1 日发布 Keycloak 26.8.0，SCIM API 与多集群「无状态」模式转为正式支持。 这条更新落在「前置部署」Forward Deployed Engineer（FDE）在企业里最难绕开的一段：身份与权限。「前置部署」Forward Deployed Engineer（FDE）把一套 AI 系统交给客户时，几乎总要回答同一个问题——机器要以谁的身份调用接口。Keycloak 26.8.0 给出的答案是一个新的参数化作用域 delegation:client:<client-id>，「前置部署」Forward Deployed Engineer（FDE）可以把它当成「智能体身份」的第一个落地点。同一次发布里还有两件事直接改变交付动作：SCIM API 由预览转为正式，多集群可以不再依赖外部 Infinispan 缓存，「前置部署」Forward Deployed Engineer（FDE）在隔离环境里少了一组必须运维的中间件。FDE 读完能拿到的是一张按功能列出状态变更、开关名与风险的清单，而不是一份版本公告。 SCIM API 从预览转为正式支持。SCIM（System for Cross-domain Identity Management）是一套用标准接口管理域内用户与组的协议，用来对接企业已有的身份管理系统。这次转正伴随着一批补强：支持多值用户属性、接入用户档案（User Profile）权限、在检索条件里支持细粒度管理权限（FGAP），并改善了大规模用户量下的检索性能。「前置部署」Forward Deployed Engineer（FDE）在客户现场做用户批量同步时，此前只能走管理 REST 接口或自建脚本，现在可以按标准协议交付，FDE 也就不用为客户每换一套身份系统重写一次同步逻辑。 多集群 v2 与「无状态」（stateless）模式从预览转为正式支持。改动的关键在架构：会话数据改为存放在数据库里，因此两个及以上 Keycloak 集群之间不再需要外部的 Infinispan 集群做跨站点复制。这个功能默认关闭，需要在启动时加 --features=stateless 打开。与之相对，多集群 v1 也就是 multi-site 特性被标记为废弃，并将在未来的主版本里移除，原先使用 --features=multi-site 的部署需要迁移到 --features=stateless。「前置部署」Forward Deployed Engineer（FDE）在客户现场做高可用方案时，少一个外部缓存集群意味着少一份容量规划、备份策略与故障演练，FDE 的交付面缩小了，回滚面也缩小了。 大表索引改为启动后在后台非阻塞创建，这是本次最有工程价值的一处修补。改动前的做法是：升级时遇到大表，为了避免启动被阻塞，模式迁移会直接跳过这些索引的创建，运维人员必须事后手工补建。跳过一旦发生而没人发现，查询就会在没有索引的表上跑，表现为升级后系统「莫名变慢」却找不到报错。现在的做法是启动完成后再用非阻塞方式创建被跳过的索引，已支持 PostgreSQL、Oracle、MySQL/MariaDB 以及受支持的 Microsoft SQL Server 版本；此前失败尝试在 PostgreSQL 上留下的无效索引会被自动识别并重建。在不支持非阻塞建索引的数据库上，Keycloak 仍然只把 SQL 打进日志，留人工执行。「前置部署」Forward Deployed Engineer（FDE）可以把这条写进升级检查单的最后一栏，FDE 要确认的是日志里没有残留待执行的建索引语句。 面向 AI 智能体的委派是这次新增的主体功能，本质是一次「令牌交换」：用户可以经由 OAuth 同意，把一个客户端的代表权授予某个应用。实现方式是一个新的参数化作用域 delegation:client:<client-id>，签发出来的令牌里带一个 act 声明，标明真正动手的是哪个客户端。设计上与管理员用户委派刻意分开：即使这个客户端持有服务账号凭据，客户端委派也不会附带管理 API 的访问权，所以一枚泄露的委派令牌无法顺着权限链升级成管理员。delegation:user 与 delegation:client 两个客户端作用域会在所有域中自动创建为可选作用域，委派授权一律由「细粒度管理权限」V2 的 delegate 与 delegate-members 控制。「前置部署」Forward Deployed Engineer（FDE）在为客户设计智能体权限时，可以用「委派不等于提权」这一条答复客户安全团队最常见的质疑，FDE 也就不必为每个智能体单开一套服务账号。 委派这条链路上还有四个细节决定它能不能过合规审查。第一，委派审计事件现在包含客户端身份，事后能追到是哪个应用代替用户动了手。第二，标准「令牌交换」会拒绝携带委派声明的被交换令牌，堵住绕过委派直接换取权限的路径。第三，新增一个客户端策略执行器，用来限制访问令牌里的 may_act 声明，把「哪些客户端可以参与委派」交给管理员逐客户端控制。第四，这个功能的支持状态是预览，不是正式。「前置部署」Forward Deployed Engineer（FDE）在客户现场决定要不要上预览功能时，FDE 需要先确认客户是否接受未来版本里行为变更，以及是否有替代方案兜底。 「参数化作用域」（原名动态作用域）从实验状态转为预览。它允许客户端在 OAuth 授权请求里把参数值随作用域名一起传进来，适合那些取值多到无法预先枚举的场景，官方举的例子是项目名这种形如 project:12345 的取值，避免为了每一种取值都在 Keycloak 里预先定义一个客户端作用域。「前置部署」Forward Deployed Engineer（FDE）在客户现场遇到多租户或按项目授权时，FDE 可以把「不要为每个租户建一个作用域」当成默认约束，否则作用域数量会随租户数线性膨胀，管理界面最先失控。 客户端「密钥轮换」（Client Secret Rotation）从预览转为正式支持。它解决的是生产环境里换密钥必须停机的问题：轮流生效的密钥最多可以有两个同时有效，新密钥启用后旧密钥仍然接受，等所有调用方切换完成再把旧的作废，因此整个轮换过程不需要服务中断。管理员可以提前规划轮换时间表，并预判应用何时需要采用新密钥。「前置部署」Forward Deployed Engineer（FDE）在客户现场做「密钥轮换」时，「同时最多两个有效密钥」就是可执行的排期规则，FDE 可以据此把密钥轮换从一次性改造变成例行操作。 新建用户时的邀请邮件不再需要外部脚本。改动前，给新用户发邀请邮件要么靠外部自动化，要么调用管理 REST 接口的 execute-actions-email 端点。新增的 invite-user 工作流步骤会在用户被创建时自动发出动作令牌邮件，不需要外部工具，也不需要自己写工作流步骤提供者。管理员可以配置用户必须完成的动作，默认是更新密码与验证邮箱，并且可以指定完成后的跳转客户端与重定向地址。「前置部署」Forward Deployed Engineer（FDE）在客户现场做用户上线流程时，FDE 可以把这段逻辑从集成代码搬回 Keycloak 配置，少一处外部依赖就少一个上线当天的故障点。 客户端管理 API v2 从实验状态转为预览。这个接口提供严格校验、声明式配置，以及一份准确的 OpenAPI 描述，用于管理 OIDC 与 SAML 客户端；可以通过 Java 客户端、自动生成的 JavaScript 客户端以及命令行使用。Keycloak Operator 也用它来声明式管理客户端，对应的自定义资源 KeycloakOIDCClient 与 KeycloakSAMLClient 同步升为预览。开启方式是启动时加 --features=preview，或者只开这一项 --features=client-admin-api:v2。「前置部署」Forward Deployed Engineer（FDE）在客户现场做 GitOps 交付时，客户端配置能从命令行与自定义资源两条路写入，FDE 手上的配置就更容易进版本库，而不是只活在管理界面里。 「模拟登录」（impersonation）的可追溯性补上了两个缺口。改动前，管理员代替某个用户登录之后，下游资源服务器与审计系统没有办法可靠地判断这枚令牌出自模拟登录，也无从知道模拟者是谁。现在令牌生命周期事件，包括 CODE_TO_TOKEN 与 REFRESH_TOKEN，都会带上 impersonator 与 impersonator_id 信息，形成完整的审计轨迹。同时，模拟登录会话签发的访问令牌与 ID 令牌都会带上 act 声明，标准依据是 RFC 8693 第 4.1 节。这个声明始终存在，不能关闭。「前置部署」Forward Deployed Engineer（FDE）在客户现场面对审计部门时，FDE 可以把「谁在什么时候以谁的名义做了什么」这条链完整拿出来，这是很多受监管行业能否验收的前提。 登录失败记录默认改为写进数据库。「暴力破解」检测的数据此前放在内存里，集群重启之后临时锁定的用户就会自动解锁，攻击者只要等到一次重启就能继续尝试。现在这些数据默认持久化在数据库里，被锁定的用户在集群重启后仍然保持锁定。使用 multi-site 与 clusterless 特性的部署仍然把登录失败写在外部 Infinispan 集群里。旧的内存行为被保留为 login-failures:v1，但已标记为废弃。「前置部署」Forward Deployed Engineer（FDE）在客户现场做安全基线时，FDE 应当确认升级后暴力破解检测的存储位置，因为锁定状态从易失变为持久，也意味着误锁用户不会随重启自动恢复。 集群名与节点名有了正式的启动参数。内嵌缓存的集群名与节点名可以用 --cache-embedded-cluster-name 与 --cache-embedded-node-name 配置，替代此前必须依赖的底层 SPI 选项。这项改动的动机是可观测性：节点名默认是每次启动随机生成的值，重启之后日志、指标与 JGroups 诊断信息无法关联到同一个节点。使用 Keycloak Operator 部署时，节点名会自动设为 Kubernetes 的 Pod 名；在 Kubernetes 上手工部署可以用 downward API 把 Pod 名注入 KC_CACHE_EMBEDDED_NODE_NAME；非 Kubernetes 环境则显式传入 --cache-embedded-node-name=<name>。「前置部署」Forward Deployed Engineer（FDE）在客户现场排查集群问题时，FDE 先确认节点名是否稳定，再去看监控图，否则会在一张节点身份不断变化的图上找规律。 出站 HTTP 客户端新增一个基于 Vert.x 的实现，状态是实验。改动前，Keycloak 对「身份提供商」、OCSP 响应方与后通道登出端点等所有对外连接，统一使用 Apache HTTP Client；而入站流量已经跑在 Vert.x 与 Netty 上，再为出站维护一套独立 HTTP 栈会带来多余的复杂度与依赖开销。开启方式是启动时加 --features=http-client:v2，开启后所有出站 HTTP 流量改用 Vert.x 客户端，既有配置项的行为保持不变。「前置部署」Forward Deployed Engineer（FDE）在客户现场处理企业代理与 TLS 检查时，FDE 换 HTTP 栈之前必须先在预发环境把身份提供商回调与后通道登出跑一遍，因为出站路径换实现，出问题的地方往往在证书与代理握手这一层。 HTTPS 证书支持加密的 PKCS#8 私钥。此前要把加密私钥用在 Keycloak 上，必须先把密钥转成不加密格式，或者改用密钥库文件，两道额外的搬运步骤既增加操作成本，也让明文私钥在磁盘上多停留一次。现在可以直接提供 PEM 格式的加密 PKCS#8 私钥，用新增的 --https-certificate-key-file-password 传入解密口令；管理接口对应使用 --https-management-certificate-key-file-password。「前置部署」Forward Deployed Engineer（FDE）在客户现场面对密钥管理规定时，FDE 可以不再为了合规把私钥降级成明文文件，这条改动对金融与政务客户尤其省事。 遗留适配器节点注册端点的服务端请求伪造风险有了开关。改动前，一个保密客户端可以向 /clients-managements/register-node 注册一个攻击者选定的主机名，Keycloak 随后会用这个主机名作为登出传播与推送吊销等管理回调的目标。新增的客户端策略执行器 secure-client-node-hostname 会把节点主机名与管理员配置的正则列表比对，不匹配的注册请求直接被拒绝。要注意两点：这项防护是选择性开启的，必须显式配置才会生效；主机名模式匹配的是 DNS 主机名与 IPv4 地址，端口后缀一律拒绝。「前置部署」Forward Deployed Engineer（FDE）在客户现场做安全基线加固时，FDE 应当把它列为必改项而不是可选项，因为默认状态下这条路径仍然开放。 26.8.0 一并修复了六个 CVE，这构成升级的硬理由。CVE-2026-12388 是身份代理映射器导致的管理员角色提升问题；CVE-2026-14781 是 OIDC 代理把 id_token 的 email_verified 应用到 userinfo 的邮箱上，使未验证地址被标成已验证；CVE-2026-19608 是仅按名称的组声明让同名组满足了按路径限定的组策略；另外三个在依赖里，分别是 jackson-databind 的 CVE-2026-54515 与 CVE-2026-59889，以及 netty-codec-http 的 CVE-2026-59903。「前置部署」Forward Deployed Engineer（FDE）在客户现场排升级窗口时，FDE 可以把「验证过的邮箱可能被伪造」当成向业务方解释紧急度的最短路径。 组织（Organizations）特性有一处会改变现有行为的默认值。标识提供商现在可以挂到多个组织上，每条链接各自带自己的自动加入与成员类型配置；域名路由从标识提供商移到了域名实体上，域名闸门保证即便多个组织共用同一个标识提供商，用户也只会被自动加入认领其邮箱域的那个组织。需要注意：升级后新建的标识提供商链接默认是 Unmanaged 成员类型，升级前已存在的链接会被迁移为 Managed，以保留原有行为。「前置部署」Forward Deployed Engineer（FDE）在客户现场做完升级后，FDE 必须按这条差异核对新建与历史链接的成员类型。 登录页的社交标识提供商区域被重做了视觉。图标、分隔布局与按钮文案都发生了变化，官方在升级指南里专门提醒：使用自定义登录主题的部署需要先比对改动。「前置部署」Forward Deployed Engineer（FDE）在客户现场提交升级之前，FDE 应当把自定义主题的登录页截图比对列为回归项，这是最容易在升级后由业务方先发现、而技术验收单里最常漏掉的一项。 这次发布里作者自己标注的局限与未覆盖场景同样要写清楚。第一，整个发布说明没有给出任何吞吐、延迟或内存占用的量化对比，「降低内存占用」只有定性描述，读者无法据此推算自己环境里的收益。第二，面向 AI 智能体的委派、参数化作用域、客户端管理 API v2 都还只是预览，不是正式支持，未来版本可能出现不兼容变更。第三，Vert.x 出站 HTTP 客户端与 OID4VP、mdoc 凭据格式都还是实验状态。第四，多集群 v2 默认关闭，必须显式打开才能生效。第五，官方附带的示例应用只用于演示，明确声明不受支持。第六，不支持非阻塞建索引的数据库仍然需要人工执行 SQL，这次改动没有覆盖它们。「前置部署」Forward Deployed Engineer（FDE）把这几条写进方案的风险栏，可以避免把预览功能当成投产承诺。 - 「前置部署」Forward Deployed Engineer（FDE）升级前的第一个动作是备份并记录当前状态：记下 --features 的实际取值，以及暴力破解检测数据当前存在哪里，因为登录失败记录默认落库这一项会让锁定状态变成持久。 - FDE 在客户现场做高可用改造时，把 --features=multi-site 换成 --features=stateless，并按官方迁移指南走 v1 到 v2 的路径，目标是去掉外部 Infinispan 集群与它的跨站点复制。 - 「前置部署」Forward Deployed Engineer（FDE）升级后收工前查一次服务端日志：确认没有残留的待手工执行建索引 SQL；如果数据库不支持非阻塞建索引，这条 SQL 就是必须补的动作。 - FDE 为客户设计智能体身份时用 delegation:client:<client-id> 发起委派，走 OAuth 同意拿到带 act 声明的令牌，不要给智能体配服务账号再模拟用户，因为委派不会附带管理 API 权限。 - 「前置部署」Forward Deployed Engineer（FDE）把委派的授权收口到细粒度管理权限 V2：用 delegate 与 delegate-members 决定谁能委派，再用客户端策略执行器限制访问令牌里的 may_act 声明。 - FDE 轮换客户端密钥时按「同时最多两个有效」排期：先启用新密钥并保持旧密钥有效，等所有调用方切换完成后作废旧密钥，全程不需要停机。 - 「前置部署」Forward Deployed Engineer（FDE）在 Kubernetes 上把节点名固定下来：Operator 部署会自动用 Pod 名，手工部署用 downward API 注入 KC_CACHE_EMBEDDED_NODE_NAME，非 Kubernetes 环境显式传 --cache-embedded-node-name。 - FDE 给客户写升级建议时的回退方式：预览与实验功能都可以不开启，把 --features=http-client:v2 与 --features=stateless 留在关闭状态；登录失败记录如需退回旧行为可用已废弃的 login-failures:v1，但这是临时手段，长期应当接受数据库持久化。 原始来源： - https://github.com/keycloak/keycloak/releases/tag/26.8.0 - https://www.keycloak.org/docs/latest/release_notes/index.html - https://www.keycloak.org/docs/latest/upgrading/index.html - https://www.keycloak.org/securing-apps/token-exchange - https://www.keycloak.org/high-availability/multi-cluster-v2/introduction - https://www.keycloak.org/high-availability/multi-cluster-v2/migrate-from-v1-to-v2