Keycloak 26.6.0: Open-Source-Identitätsmanagement
Keycloak 26.6.0 markiert einen der größten Entwicklungsschritte der Plattform seit der umfassenden Umstellung auf den Quarkus-Stack. Die Veröffentlichung schließt langfristige Baustellen in der Architektur und führt mehrere Funktionen aus dem Vorabstatus in den voll unterstützten Betrieb über. Damit endet eine Phase technischer Übergänge, in der viele Kernfunktionen experimentell waren. Entscheidend ist, dass damit erstmals ein stabiler Rahmen für kontinuierliche Updates und reproduzierbare Deployments entsteht.
Die Zero-Downtime-Patch-Releases zeigen, wie Keycloak auf Anforderungen großer, hochverfügbarer Umgebungen reagiert. Bisher mussten Betreiber Instanzen neu starten, was bei verteilten Kubernetes-Clustern zu Authentifizierungsabbrüchen führen konnte. Jetzt lassen sich Patches parallel auf Nodes ausrollen, während die Session-Verwaltung aktiv bleibt. Das geschieht, indem Keycloak zukünftige und aktuelle Versionen gleichzeitig unterstützt und Sitzungsdaten in der Datenbank für beide kompatibel hält. Für Unternehmen mit SSO-Diensten über mehrere Regionen hinweg bedeutet das, dass Wartungsfenster entfallen und Authentifizierungssysteme rund um die Uhr online bleiben. Damit nähert sich Keycloak in seiner Update-Strategie Systemen wie OpenShift oder großen Cloud-Anbietern an, die Rolling Updates seit Jahren etabliert haben.
Mit der Federated Client Authentication öffnet sich Keycloak stärker für Multi-Tenant- und Multi-Provider-Szenarien. Bisher war es nur möglich, Benutzeridentitäten föderiert zu behandeln. Jetzt lässt sich dieselbe Logik auch auf Clients anwenden. Anwendungen, die sich bei unterschiedlichen Identity Providern registriert haben, können innerhalb einer zentralen Keycloak-Instanz Authentifizierungsanfragen austauschen. Das ist besonders für Zusammenschlüsse von Organisationen relevant, die ihre Zugriffsinfrastruktur konsolidieren möchten. Praktisch kann damit etwa eine Anwendung, die AzureAD nutzt, dieselben Zugriffstoken in Keycloak-gestützten Diensten verwenden, ohne Code-Anpassungen oder doppelte Registrierung.
Der JWT Authorization Grant nach RFC 7523 ist seit Jahren in zahlreichen Unternehmens-APIs im Einsatz, wurde in Keycloak jedoch nur unvollständig unterstützt. Durch die jetzt vollständige Implementation können externe Systeme signierte JWTs direkt gegen Access Tokens eintauschen, ohne dedizierte Austausch-APIs zu implementieren. Das schafft eine klarere Trennung zwischen Token-Vergabe und Service-Integration und reduziert Wartungsaufwände. Für Unternehmen, die OpenID-Connect-Strukturen mit Legacy-Systemen verbinden, schließt dies eine Lücke zwischen automatisierten Maschinen-Zugriffen und menschlicher Authentifizierung.
Das neue Test Framework ersetzt die alte Infrastruktur auf Arquillian-Basis. Diese war eng mit Jakarta-EE-Containern verknüpft und nur schwer wartbar. Das neue Framework integriert sich direkt in den Build-Prozess auf Maven-Ebene und nutzt Containerisierung, um reproduzierbare Testumgebungen zu erzeugen. Davon profitieren sowohl Kernentwickler als auch externe Beitragende. Regressionstests, die bisher Stunden benötigten, können nun parallelisiert und in CI/CD-Pipelines integriert werden. Dadurch verringert sich die Gefahr, dass Änderungen an der API unbemerkt fehlerhafte Integrationen auslösen.
Mit der Einführung des OAuth Client ID Metadata Document (CIMD) experimentiert Keycloak erstmals mit Metadaten-basierten Client-Discovery-Mechanismen. Das Konzept erlaubt es Anwendungen, Konfigurationen automatisiert aus JSON-Dokumenten zu laden, statt manuell in der Administrationskonsole angelegt zu werden. Diese Funktion ist für zukünftige Multi-Client-Protokolle, insbesondere Machine Communication Protocols (MCP), relevant. In komplexen IoT- oder Service-Mesh-Strukturen können damit Clients dynamisch registriert und verwaltet werden, ohne dass Zuständigkeiten zentral gebündelt werden müssen.
Parallel hat Keycloak in Version 26.6.0 mehrere organisatorische und technische Aufräumarbeiten durchgeführt. Die Unterstützung für OpenJDK 25 und aktualisierte Bibliotheken bringt Kompatibilität mit neuen JVM-Versionen und Container-Builds. In Multi-Organisation-Setups erlauben isolierte Gruppenhierarchien eine saubere Trennung von Namensräumen, sodass Unternehmensmandanten keine Gruppen- oder Rollenbezeichner mehr teilen müssen. Außerdem hat das Projektteam die Helm-Charts überarbeitet, um den Betrieb auf Kubernetes weiter zu vereinfachen und die Migration von Ingress-Konfigurationen zwischen Versionen zu automatisieren.
Schlagwörter: Keycloak + CIMD
Wie bewerten Sie den Schreibstil des Artikels?