IT-Sicherheit
Keycloak
Keycloak ist ein quelloffener Identity Provider und IAM-Server für Single Sign-on über OpenID Connect, OAuth 2.0 und SAML; CNCF-Inkubationsprojekt, von Red Hat.
- Identity Provider, quelloffen
- SSO: OIDC, OAuth 2.0, SAML
- Realms, Clients, User Federation
- MFA, Identity Brokering
- Apache-2.0, CNCF-Projekt
Keycloak ist ein quelloffener Identity Provider: Anwendungen überlassen ihm die Anmeldung und nutzen über ihn Single Sign-on. Es spricht die gängigen Standards OpenID Connect, OAuth 2.0 und SAML, stammt ursprünglich von Red Hat und ist seit 2023 ein Inkubationsprojekt der Cloud Native Computing Foundation (CNCF).
Dieser Artikel erklärt die Kernbegriffe Realm, Client und Rolle, die Anbindung bestehender Verzeichnisse und externer Identity Provider, die anpassbaren Authentifizierungs-Flows mit MFA, die Quarkus-Basis und das Deployment, die Hochverfügbarkeit sowie die Sicherheits- und Betriebsfragen.
1. Realms, Clients, Rollen
Die oberste Einheit in Keycloak ist der Realm: ein vollständig getrennter Container mit eigenen Nutzern, Rollen, Gruppen, Clients und Einstellungen, ideal zur Trennung von Mandanten oder Umgebungen (Produktion/Test). Ein Client ist eine Anwendung oder API, die Keycloak zur Authentifizierung nutzt. Rollen und Gruppen steuern die Zugriffskontrolle und lassen sich realmweit oder clientspezifisch vergeben.
2. Verzeichnisse und externe Provider
Keycloak steht selten allein. Über User Federation bindet es bestehende Verzeichnisse wie LDAP oder Active Directory ein (eigener Artikel), ohne Passwörter migrieren zu müssen, die Prüfung erfolgt weiter gegen das Verzeichnis. Über Identity Brokering delegiert Keycloak die Anmeldung an externe Identity Provider (etwa andere OIDC-/SAML-IdPs oder Social Login) und tritt dabei als Vermittler auf: IdP gegenüber der Anwendung, Client gegenüber dem externen Provider.
3. Flows und MFA
Die Authentifizierungs-Abläufe (Flows) für Login, Registrierung und Passwort-Reset sind vollständig konfigurierbar; einzelne Schritte lassen sich als erforderlich, alternativ oder bedingt schalten. Für die MFA (eigener Artikel) unterstützt Keycloak TOTP-Apps sowie WebAuthn und Passkeys; MFA lässt sich gezielt erzwingen, etwa für privilegierte Rollen.
4. Quarkus-Basis und Deployment
Mit Version 17 wurde die Quarkus-Distribution eingeführt; die ältere WildFly-Distribution wurde mit Version 20 endgültig entfernt. Das bringt schnellere Starts und ein vorhersagbares, container-freundliches Verhalten. Eine Besonderheit ist der Build-Schritt: Optionen, die etwa den Datenbank-Treiber betreffen, werden beim Image-Build eingebacken. Betrieben wird Keycloak per Container oder auf Kubernetes (mit Operator) und benötigt eine externe Datenbank (PostgreSQL ist die verbreitete Wahl).
5. Hochverfügbarkeit
Für die Verteilung von Sitzungen und Tokens nutzt Keycloak einen verteilten Cache (Infinispan). Im einfachsten Fall verteilt man die Instanzen über mehrere Zonen eines Kubernetes-Clusters; für höhere Anforderungen gibt es Multi-Cluster-Aufbauten mit externem Infinispan. Diese Topologien sind leistungsfähig, aber betrieblich anspruchsvoll und gehören sorgfältig geplant.
6. Sicherheit und Betrieb
Als zentraler Identity Provider ist Keycloak ein hochattraktives Angriffsziel: Eine kompromittierte Instanz gefährdet alle angebundenen Anwendungen. Daraus folgen klare Pflichten: die Admin-Konsole nicht öffentlich exponieren, MFA für Admin-Konten, restriktive Client-Scopes und Token-Laufzeiten sowie zeitnahes Einspielen von Sicherheitsupdates. Im Community-Projekt wird jeweils die aktuelle Hauptversion mit Sicherheitsfixes gepflegt; wer feste Langzeitunterstützung braucht, kann auf das kommerziell unterstützte Red-Hat-Derivat zurückgreifen.
Der Identity Provider ist das Generalschlüssel-System. Eine ungehärtete, öffentlich erreichbare Keycloak-Admin-Konsole ist kein Detail, sondern das größte Einzelrisiko der ganzen Anmeldekette.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Standardkonform (OIDC, OAuth 2.0, SAML), CNCF-getragen | hohe Komplexität, erfordert IAM-Kompetenz |
| User Federation (LDAP/AD) ohne Passwort-Migration | Major-Upgrades mit möglichen Breaking Changes |
| Identity Brokering und Social Login | JVM/Java-Overhead (schwergewichtiger als schlanke Dienste) |
| Anpassbare Flows, MFA inkl. Passkeys | zentrales Angriffsziel, Härtung nicht automatisch |
| Apache-2.0, kommerzieller Support-Pfad (Red Hat) | HA/Multi-Cluster betrieblich aufwendig |
Häufige Fragen zu Keycloak
Ein Realm ist die oberste Isolationseinheit in Keycloak: ein vollständig getrennter Container mit eigenen Nutzern, Rollen, Gruppen, Clients und Konfigurationen. Realms teilen sich zwar dieselbe Keycloak-Instanz, sind aber voneinander abgeschottet. Typische Nutzung ist ein Realm pro Mandant oder pro Umgebung (Produktion, Test). So lassen sich unterschiedliche Nutzerkreise und Anwendungen sauber voneinander trennen.
Ja. Über die User Federation bindet Keycloak LDAP- und Active-Directory-Verzeichnisse ein. Dabei müssen keine Passwörter migriert werden, die Authentifizierung läuft weiterhin gegen das Verzeichnis. Wahlweise werden Benutzer lokal importiert und synchronisiert oder direkt aus dem Verzeichnis gelesen. Damit fügt sich Keycloak in eine vorhandene Identitätslandschaft ein, statt sie zu ersetzen.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Keycloak im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.