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)

Mitte Februar lief in den USA die Finanzierung für das Heimatschutzministerium DHS (Department of Homeland Security) und damit der IT-Sicherheitsbehörde CISA aus. Die läuft seitdem im Notbetrieb mit eingeschränkten Ressourcen weiter.

Wie CBS News jetzt berichtet, sollen alle DHS-Angestellten bis Ende dieser Woche das Gehalt für die vergangenen sechs Wochen des Shutdowns erhalten. Das hat Markwayne Mullin, Minister für Heimatschutz, demnach am Dienstag dieser Woche angekündigt. Er sagte, dass die meisten dieser Schecks bis Freitag bei den Banken angekommen sein sollten. Einige Finanzinstitute müssten bis Montag warten, aber die Mehrheit von allen solle bis dahin bezahlt worden sein.

Die Zahlungen sollen durch Flexibilität in der Mittelverwendung und Exekutivmaßnahmen möglich gemacht worden sein. Mullin warnte jedoch zugleich, dass die künftigen Zahlungen für DHS-Angestellte – mit Ausnahme von Strafverfolgungsbeamten – vollständig vom US-Kongress abhingen. CBS News zufolge kritisierte Mullin die Demokraten scharf wegen der Verzögerungen. Er warf ihnen vor, dazu bereit zu sein, 22 Behörden die Mittel zu entziehen, die zur Aufgabe haben, die innere Sicherheit zu gewährleisten, vom Pentagon bis zum DHS.

Lob für Angestellte

Zugleich lobte er die Angestellten der Behörden, die trotz Unsicherheiten bezüglich der Gehaltszahlungen weiter zur Arbeit erschienen. Das sei ein unglaubliches Engagement. Auf Rückfragen, wie die Mittel verfügbar gemacht wurden, verwies Mullin auf Notfallbefugnisse, die dem Präsidenten die begrenzte Umschichtung von Mitteln erlauben.

Der Behörden-Shutdown ist Folge eines Streits zwischen Republikanern und Demokraten über das Verhalten von Beamten der Polizei- und Zollbehörde United States Immigration and Customs Enforcement (ICE). Sie konnten sich infolgedessen nicht auf Bedingungen für eine weitere Finanzierung des DHS einigen.

(dmk)

Cloudflare beschleunigt seine Post-Quantum-Migration und plant bis 2029 die vollständige Umstellung – inklusive quantensicherer Authentifizierung. Das Unternehmen reagiert damit auf aktuelle Fortschritte in der Quantencomputer-Forschung, die den Zeitrahmen für die Bedrohung durch Quantenangriffe verkürzen.

Post-Quantum-Kryptografie bezeichnet Verfahren, die auch Angriffen durch Quantencomputer standhalten sollen. Weit verbreitete Public-Key-Verfahren wie RSA oder Elliptic Curve Cryptography (ECC) lassen sich mit Quantenalgorithmen wie Shor prinzipiell brechen. Sicherheitsforscher warnen zudem vor dem Szenario „Harvest now, decrypt later“ (HNDL): Angreifer könnten bereits heute verschlüsselte Daten abgreifen und sie später mit Quantencomputern entschlüsseln. Das macht eine frühzeitige Umstellung auf neue Verfahren dringlich.

Verschlüsselung steht, Authentifizierung folgt

Im Kern setzt Cloudflare bereits seit 2022 auf hybride Verschlüsselung (Kyber + ECDHE), um HNDL-Angriffe zu verhindern. Sollte sich eines der beiden Verfahren künftig als unsicher erweisen, bleibt die Verbindung durch das jeweils andere geschützt. Gleichzeitig ermöglicht der Ansatz eine schrittweise Migration, ohne bestehende Infrastruktur zu brechen. Jetzt folgt die Umstellung der Authentifizierung auf das gitterbasierte Verfahren Dilithium.

Dabei greift Cloudflare auf Algorithmen aus dem Standardisierungsprozess des National Institute of Standards and Technology (NIST) zurück, allen voran das gitterbasierte Verfahren Kyber für den Schlüsselaustausch. Gitterbasierte Verfahren gelten als aussichtsreich, weil sie auf mathematischen Problemen beruhen, die auch Quantencomputer nicht effizient lösen können.

Roadmap bis 2029 in mehreren Etappen

Die Post-Quantum-Verschlüsselung ist seit 2022 standardmäßig aktiv. Über 65 Prozent des menschlichen Datenverkehrs zu Cloudflare ist damit bereits post-quantum-verschlüsselt. Die Umstellung der Authentifizierung auf Dilithium erfolgt in mehreren Etappen: Mitte 2026 für Origin-Verbindungen, Mitte 2027 für Besucher-Verbindungen, Anfang 2028 für Enterprise-Netzwerke und vollständig bis 2029. Kunden müssen dafür keine Einstellungen ändern. Cloudflare unterstützt bereits hybride Verschlüsselung, aber Clients müssen Post-Quanten-Verfahren ebenfalls implementieren, um sie zu nutzen.

Für HTTPS bleibt klassische Kryptografie vorerst aktiv, um Kompatibilität zu wahren. Cloudflare nutzt Mechanismen wie PQ HSTS und Certificate Transparency, um Downgrade-Angriffe zu verhindern.

Weitere Informationen zur neuen Roadmap finden sich in der Ankündigung von Cloudflare.

(fo)