Keycloak 26.6 bringt Zero-Downtime-Updates und Workflows

Das Keycloak-Projekt hat Version 26.6.0 des Open-Source-Identity-Providers veröffentlicht. Im Mittelpunkt stehen fünf Features, die den Preview-Status verlassen und nun als vollständig unterstützt gelten. Für Unternehmen, die Keycloak in Kubernetes-Umgebungen betreiben, dürften dabei vor allem die Zero-Downtime-Patch-Releases und die Federated Client Authentication relevant sein.

Die wohl praxisrelevanteste Neuerung laut Ankündigung: Patch-Releases lassen sich künftig als Rolling Updates innerhalb eines Minor-Release-Streams einspielen, ohne dass der Dienst unterbrochen wird. Zusammen mit dem ebenfalls verbesserten Graceful HTTP Shutdown, der Fehlermeldungen beim Abschalten einzelner Nodes verhindert, greift das Entwicklungsteam damit eine zentrale Anforderung containerisierter Deployments auf. Um von den Zero-Downtime-Patch-Releases profitieren zu können, genügt es laut Release Notes, die Update-Strategie für den Keycloak Operator auf „Auto“ zu setzen.

Daneben hat das Projekt die Federated Client Authentication in den produktiven Status befördert. Das Feature erlaubt es Clients, vorhandene Credentials eines externen Issuers zu nutzen, sobald eine Vertrauensbeziehung besteht. Individuelle Client-Secrets in Keycloak entfallen damit. Unterstützt werden Client-Assertions externer OpenID-Connect-Identity-Provider sowie Kubernetes Service Accounts. Organisationen mit mehreren Identity-Providern reduzieren so den Verwaltungsaufwand für Secrets erheblich. Die OAuth-SPIFFE-Client-Authentication bleibt allerdings im Preview-Status, da die zugrunde liegende Spezifikation noch nicht finalisiert ist.

Workflows und JWT Authorization Grant

Mit den nun unterstützten Workflows bringt Keycloak zentrale Funktionen aus dem Bereich Identity Governance and Administration (IGA) mit. Administratoren können Realm-Aufgaben wie das Lifecycle-Management von Benutzern und Clients in YAML-Dateien definieren und anhand von Ereignissen, Bedingungen oder Zeitplänen automatisiert ausführen lassen. Das Release enthält zudem neue Built-in-Steps, einen Troubleshooting-Guide sowie diverse Verbesserungen an der Workflow-Engine.

Auch der JWT Authorization Grant nach RFC 7523 gilt nun als produktionsreif. Er ermöglicht den Austausch externer JWT-Assertions gegen OAuth-2.0-Access-Token und hilft somit bei Anwendungsfällen, in denen externe Token in interne überführt werden müssen. Komplettiert wird das Quintett durch das neue Keycloak Test Framework, das den bisherigen Arquillian-basierten Ansatz ablöst.

Experimentelle MCP-Unterstützung und Java 25

Jenseits der fünf Haupt-Features liefert das Release weitere Neuerungen. Experimentell unterstützt Keycloak nun das OAuth Client ID Metadata Document (CIMD) – ein aufkommender Standard zur Beschreibung von OAuth-2.0-Client-Metadaten. Da das Model Context Protocol (MCP) ab Version 2025-11-25 CIMD voraussetzt, lässt sich Keycloak künftig als Authorization Server für MCP-Szenarien nutzen.

Als Preview erscheinen zudem die Identity Brokering APIs V2, die den Legacy Token Exchange V1 ablösen sollen, sowie Step-up Authentication für das SAML-Protokoll. Organisationen profitieren außerdem von isolierten Gruppenhierarchien pro Organisation, die Namenskonflikte innerhalb eines Realms vermeiden.

Auf der Infrastrukturseite unterstützt Keycloak inzwischen OpenJDK 25. Das Container-Image setzt allerdings weiterhin auf Java 21, um FIPS-Kompatibilität zu gewährleisten – für Unternehmen in regulierten Umgebungen bleibt damit alles beim Alten. Bestehende Deployments mit Java 21 sollen unverändert weiter funktionieren. Weitere Verbesserungen betreffen die automatische Truststore-Initialisierung auf Kubernetes und OpenShift, neue Client-Certificate-Lookup-Provider für Traefik und Envoy sowie überarbeitete HTTP-Access-Logs, die sensible Informationen wie Token und Cookies ausfiltern.

Hinweise zum Upgrade

Vor dem Update auf Keycloak 26.6.0 sollten Administratoren die Breaking Changes im Upgrading Guide prüfen. JavaScript-basierte Policies erfordern nun ein aktiviertes Scripts-Feature. Client-URIs müssen HTTPS verwenden, und die Issuer-Konfiguration für JWT Authorization Grant und Client Assertions muss eindeutig einen Provider identifizieren.

(map)