Identitätsmanagement: Keycloak 20 finalisiert die Migration zum neuen Operator

Der Unterbau der Open-Source-Software basiert nun auf Quarkus und löst die WildFly-basierte Distribution ab. Daraus resultieren wichtige Änderungen.

In Pocket speichern vorlesen Druckansicht 2 Kommentare lesen

(Bild: Photon photo/Shutterstock.com)

Lesezeit: 3 Min.
Von
  • Maika Möbus

Red Hat hat Keycloak in Version 20 veröffentlicht. Die Open-Source-Software für Identity and Access Management (IAM) vollendet damit planmäßig die Migration zum Quarkus-Unterbau, während die bisherige WildFly-basierte Distribution in den Ruhestand übergeht. Das erzeugt Breaking Changes und wirkt sich unter anderem auf die unterstützten OpenJDK-Versionen aus. Ein Migrationsguide hilft beim Upgrade.

Wie bereits angekündigt, versetzt Keycloak 20 den auf Red Hats Applikationsserver WildFly aufsetzenden Kubernetes-Operator in den End-of-Life-Status (EOL). An seine Stelle tritt nun der neue, auf dem Java-Framework Quarkus aufsetzende Operator, der bisher als Preview vorlag. Er hat nicht nur den Preview-Status verlassen, sondern bringt in Keycloak 20 auch einige neue Funktionen mit, die nicht abwärtskompatibel sind. Verwendungshinweise zum neuen Operator bietet die Dokumentation.

Im aktuellen Release erhält Keycloak die Möglichkeit, OpenJDK 17 für Server und Adapter zu nutzen. Dagegen entfällt gleichzeitig mit der WildFly-basierten Distribution auch der Support für das Verwenden des Keycloak-Servers mit OpenJDK 8, was ab Version 21 auch den Einsatz von Keycloak-Adaptern betrifft. Ab der übernächsten Version Keycloak 22 soll sich der Support jeweils auf das neueste OpenJDK-Release mit Long-term Support (LTS) beschränken und auch das neueste OpenJDK-Release soll schnell unterstützt werden. Demnach wird der Keycloak Server in Keycloak 22 auch mit OpenJDK 11 nicht mehr umgehen können.

Da dem neuen Keycloak Operator noch einige der Custom Resources (CR) fehlen, bietet Red Hat einen Realm Operator als temporären Workaround. Informationen dazu finden sich im GitHub-Repository sowie in einem Blogeintrag. Bereits seit Keycloak 17 gilt der Quarkus-basierte Operator als Standard. Im Zuge dessen veröffentlichte Red Hat einen Migrationsguide. Wer noch auf die WildFly-Distribution setzt, solle schnellstmöglich upgraden.

Das Entwicklungsteam hinter Keycloak möchte Windows-Nutzerinnen und -Nutzern das gleiche Erlebnis bieten wie solchen, die auf Linux setzen, und hat daher nach eigenen Angaben wichtige Änderungen an der kc.bat-Datei durchgeführt. Für den Umgang mit JavaScript setzt Keycloak 20 auf eine neue Option zum Durchsetzen von Best Practices: Derzeit können Anwendungen keycloak.js direkt vom Keycloak-Server laden, was Best Practices widerspricht. Daher steht ein neuer Feature Guard bereit, der das Deaktivieren dieser Fähigkeit erlaubt. In der nächsten Version soll sie als deprecated (veraltet) gelten und in der übernächsten soll sie komplett entfallen.

Diese und weitere Neuerungen in Keycloak 20, darunter zahlreiche Bug Fixes, beschreibt ein Blogeintrag.

(mai)