In vielen Projekten mit Keycloak taucht früher oder später dieselbe Frage auf:
Können wir Keycloak als zentrale Identitätsquelle („Single Source of Truth“) nutzen – oder brauchen wir etwas anderes?
Spoiler: Keycloak kann vieles, aber nicht alles. Dieser Beitrag beleuchtet, was Keycloak in Sachen Identitätsmanagement wirklich leisten kann – und wann man besser auf ein dediziertes Identity Management System (IDM) setzen sollte.
Was bedeutet „Single Source of Truth“ im Identity-Kontext?
Im Identity & Access Management (IAM) beschreibt die Single Source of Truth (SSoT) die zentrale, autoritative Quelle für Identitätsdaten.
Typische Aufgaben dieser Quelle:
- Benutzeranlage, -änderung und -löschung (Lifecycle)
- Verteilung der Daten an angeschlossene Systeme (z. B. AD, Cloud, Applikationen)
- Governance, Rollenmodellierung, Genehmigungsprozesse
- Grundlage für Audits und Compliance-Anforderungen
Was Keycloak leisten kann
Keycloak ist ein Open-Source Access Management System, das:
- Benutzer, Gruppen, Rollen und Attribute verwalten kann
- OAuth2, OIDC und SAML spricht – ideal für moderne Web-Anwendungen
- SSO (Single Sign-On) bietet
- Mehrmandantenfähigkeit via Realms erlaubt
- Externe Identitätsquellen (z. B. LDAP, Active Directory) anbinden kann
Kurz gesagt: Für viele Anwendungen funktioniert Keycloak sehr gut als „Identity Provider“ (IdP).
Aber: Keycloak ist kein vollständiges Identity Management System
Keycloak bietet keine Funktionen für echtes Identity Governance & Administration (IGA):
- Kein automatisiertes User Lifecycle Management (z. B. On-/Offboarding)
- Keine Genehmigungsworkflows für Rollen oder Ressourcen
- Keine integrierten Rezertifizierungen
- Keine native Integration mit HR-Systemen
- Kein Rollenmodell über Systemgrenzen hinweg
Keycloak managt Zugriffe – nicht die zugrunde liegenden Identitäten im Gesamtunternehmen.
Wann Keycloak als SSoT ausreicht – und wann nicht
Keycloak als SSoT ist sinnvoll, wenn:
- Du eine überschaubare Nutzerbasis hast
- Du eigenentwickelte oder moderne Webanwendungen mit OAuth2/OIDC betreibst
- Kein aufwendiges On-/Offboarding oder Rollenmodell nötig ist
Nicht sinnvoll, wenn:
- Du viele verschiedene Systeme anbinden musst (HR, ERP, AD, SaaS…)
- Du Compliance-Anforderungen erfüllen musst (z. B. Rezertifizierung, Audit-Trail)
- Es Genehmigungsprozesse für Rollen oder Gruppen gibt
- Deine IT-Architektur komplex und rollenbasiert organisiert ist
Praxisempfehlung: So könnte eine zukunftssichere Architektur aussehen
In komplexeren Umgebungen hat sich die folgende Aufteilung bewährt:
- Identity Management System (z. B. midPoint, One Identity, SailPoint)
→ Dient als zentrale Quelle für Identitäten, Rollen, Prozesse - Keycloak
→ Übernimmt Authentifizierung, Autorisierung und SSO für Applikationen - Synchronisation über Federation, REST-API oder SCIM
Diese Trennung bringt klare Verantwortlichkeiten und Flexibilität für Wachstum & Governance.
Fazit
Keycloak ist ein mächtiges Werkzeug für Authentifizierung und Zugriffskontrolle – aber nicht für umfassendes Identitätsmanagement gemacht.
Wer in kleinen Projekten oder bei klar abgegrenzten Anwendungsfällen arbeitet, kann Keycloak durchaus als Identitätsquelle nutzen.
In größeren, regulierten oder stark integrierten Umgebungen empfiehlt sich ein dediziertes IAM-System – mit Keycloak als leistungsfähigem Frontend für Zugriff und SSO.
