Keycloak Basics: Grundlegende Begriffe wie Realms, Clients, Token, JWT, OAuth und Rollen verstehen

Jeder Neueinsteiger in den Themenkomplex Keycloak wird zwangsläufig mit neuen Begriffen und Konzepten konfrontiert, die es während der Einrichtung und Konfiguration zu bewältigen gilt. Manche davon sind allgemeingültige Begriffe, die in der Welt des Identity- und Access-Managements immer wieder vorkommen. Andere wiederum sind sehr Keycloak-spezifisch und werden selbst IAM-Experten, die zuvor nicht mit Keycloak gearbeitet haben, nicht geläufig sein. Das liegt zum einen daran, dass Keycloak selbst eigene Konzepte mit eigenen Namen mitbringt, andererseits aber auch für bekannte Konzepte teils andere und eigene Begriffe verwendet.

Dieser Artikel hat den Anspruch, wesentliche Begriffe zu benennen, eine Übersicht zu geben und grundlegend zu erläutern. Er soll ein grobes Verständnis für alle wichtigen Begriffe, die im Keycloak-Universum eine zentrale Rolle spielen, geben.

Grundlegende IAM-Begriffe

• Benutzer
  Ein Benutzer kann eine natürliche Person oder aber auch ein Dienst (technischer Nutzer) sein, der sich an einem System authentifizieren will und auf Ressourcen zugreifen möchte. Die Identität des Benutzers muss verwaltet werden, um den Zugriff auf die angeforderten Ressourcen zu steuern.
• Authentication und Authorization
  Unter Authentifizierung (AuthN) versteht man den Prozess, in dem ein Benutzer seine Identität nachweist. Dies kann beispielsweise durch Eingabe von Benutzernamen und Passwort geschehen. Im Anschluss ist der Benutzer identifiziert und die festgestellte Identität wird in folgenden Schritten als korrekt angenommen. Autorisierung (AuthZ) ist der Prozess, der festlegt, welche Aktionen ein bestimmter (zuvor authentifizierter) Benutzer ausführen kann und auf welche Ressourcen er zugreifen darf. Authentifizierung stellt somit die Frage “Wer bist du?”, während die Autorisierung die Frage stellt “Was darfst du tun?”.
• OAuth / OpenID Connect (OIDC)
  OAuth ist ein Protokoll zur Autorisierung, während OpenID Connect eine Schicht zu OAuth hinzufügt, um Authentifizierung zu ermöglichen. OAuth erlaubt einer Anwendung (einem Client) im Namen eines Benutzers auf dessen Ressourcen, die bei einem anderen Dienst gespeichert wurden, zuzugreifen oder Aktionen in dessen Namen auszuführen.
• Client
  Ein Client ist jede Anwendung, die die Benutzer nutzen können und an der sie sich mit Hilfe von Keycloak anmelden können. Ein Client muss in der Regel wissen, mit welchem Benutzer er es zu tun hat, um entsprechend seiner Berechtigung Ressourcen zugreifbar zu machen und dem Benutzer zugehörige Ressourcen bereitzustellen. Clients unterscheiden sich bzgl. ihrer Möglichkeit, Geheimnisse (sogenannte Client Credentials) sicher vor dem Zugriff anderer zu verwahren. Public Clients haben keine Möglichkeit, Daten sicher zu speichern, da diese komplett an dem Benutzerrechner ausgeführt werden. Confidential Clients sind wiederum meist WebApps, die auf einem Server ausgeführt werden und dort Client Credentials vor Zugriff geschützt ablegen können.
• Berechtigungen
  Berechtigungen sind Regeln, die festlegen, welche spezifischen Aktionen (z. B. das Nutzen einzelner Funktionen einer Anwendung oder API) ein Benutzer ausführen darf und auf welche Informationen ein Benutzer zugreifen darf (z. B. andere Benutzer sehen oder editieren). Berechtigungen können einzelnen Benutzern zugewiesen werden, um ihnen das Recht der Ausführung einer Funktion oder der Einsicht in Daten zu gewähren.
• Rollen & RBAC
  Möchte man einem oder mehreren Benutzern direkt mehrere Berechtigungen auf einmal geben, kann man diese zuvor in einer Rolle zusammenfassen. Gibt es beispielsweise eine Rolle “Administrator”, können dieser Rolle alle Berechtigungen hinzugefügt werden, die ein Administrator benötigt. Anschließend kann man diese Rolle dann den Benutzern zuweisen, die “Administrator” sein sollen. Statt also jedem Benutzer Einzelberechtigungen zu geben, was sehr komplex und unübersichtlich werden kann, werden Berechtigungen über Rollen abgebildet. Das Vorgehen hat den Vorteil, dass man zum einen eine Sammlung an Berechtigungen direkt mehreren Benutzern zuweisen kann und zum anderen, dass sich eine spätere Veränderung einer Rolle (z. B. durch Hinzufügen oder Entfernen einer Berechtigung) direkt automatisch auf alle Benutzer dieser Rolle auswirkt, ohne dass jeder Benutzer einzeln editiert werden muss. Dieses Konzept, bei dem Benutzern Rollen statt einzelnen Berechtigungen zugewiesen werden, wird als Role-Based Access Control (RBAC) bezeichnet.
• Gruppen
  Benutzer können organisatorisch in Gruppen zusammengefasst werden. Dies sind in der Regel Benutzer, die logisch ähnliche Funktionen innerhalb einer Organisation ausüben und entsprechend auch ähnlich berechtigt werden sollten. Gruppen ermöglichen es, allen Benutzern in der Gruppe definierte Rollen und Berechtigungen zuzuweisen. Ähnlich wie bei Rollen, lassen sich auch die Eigenschaften einer Gruppe nachträglich editieren und wirken sich automatisch auf alle Gruppenmitglieder aus. Sollen beispielsweise technische Mitarbeiter sowohl Administrator als auch Nutzer sein, könnte man für sie eine Gruppe “Technische Mitarbeiter” anlegen und dieser Gruppe die Rollen “Administrator” und “Nutzer” zuweisen.
• Token / JWT
  Ein Token ist in der Regel eine zufällig aussehende Zahlen- und Buchstabenkombination, die im Gebrauch der Anwendung Benutzernamen und Passwort ersetzt. Statt sich also an jedem Dienst immer wieder mit Benutzernamen und Passwort anzumelden, wird hierfür ein zuvor erstelltes Token genutzt, das für den Auth-Prozess genutzt wird. Hierdurch kann man Authentifizierung und Autorisierung entkoppeln: Beim Tausch von Benutzername und Passwort gegen einen Token findet die Authentifizierung statt. Danach wird immer nur noch der Token zur Autorisierung genutzt. Die Logik der Identifizierung verbleibt im Keycloak und wird sonst nirgendwo benötigt. Wird als Token ein sogenanntes JSON Web Token (JWT) verwendet (bei Keycloak üblich), lassen sich in der zufällig aussehenden Zahlen- und Buchstabenkombination Informationen über den Benutzer und seine Session hinterlegen (z. B. Vor-/Nachname, E-Mail Adresse, Benutzername, Sessiondauer, etc.). Token sind nur eine bestimmte Zeit lang gültig. Generell wird zwischen drei Token unterschieden:
  • Access Token werden wie beschrieben zum Auth verwendet, wenn ein Benutzer mit einem Client interagieren möchte.
  • ID Token können optional verwendet werden, um via JWT weitere Informationen über den Benutzer zu übergeben.
  • Refresh Token werden genutzt, um nach Ablauf des Access Tokens einen neuen automatisch abrufen zu können.
• Token Flows
  Um die genannten Token abzurufen, muss einer der sogenannten Token Flows durchlaufen werden, die innerhalb von OAuth/OIDC definiert sind. Hierbei tauschen Benutzer/Client und Identity Provider (Keycloak) bestimmte Informationen aus. Der Effekt des Token Flows ist, dass Benutzername und Passwort gegen Token getauscht wurden. Der gängigste Flow für Webanwendungen ist der Authorization Code Flow.
• Scopes
  Wie beschrieben werden verschiedene Informationen in einem JWT abgelegt. Über Scopes lässt sich konfigurieren, welche Informationen das sein sollen. Der Scope “profile” sorgt so beispielsweise dafür, dass Profilinformationen des Benutzers im Token landen. Ein oder mehrere Scopes können hierzu beim Token-Abruf mit Hilfe der Token Flows angegeben werden. Es können auch benutzerdefinierte Scopes in IAM-Systemen wie Keycloak angelegt werden, um selbst definierte Informationen auszuspielen.
• Single-Sign-On
  Gibt es innerhalb eines Unternehmens mehrere Anwendungen, die ein Benutzer mit den gleichen Login-Daten nutzen können soll, spricht man von Single-Sign-On. Der Benutzer meldet sich nur einmal, zum Beispiel an Keycloak, an und kann danach alle Anwendungen des Unternehmens ohne weiteren Login nutzen.
• Multi-Factor Auth / One Time Password (OTP)
  Meist benötigt ein Benutzer nur Benutzernamen und Passwort zum Login. Wird darüber hinaus ein weiteres Merkmal abgefragt, spricht man grundsätzlich von Multi-Factor Auth. Idealerweise verwendet man ein Merkmal, das eine Interaktion des Nutzers verlangt. Ein weiteres Merkmal kann zum Beispiel ein One Time Passwort (OTP) sein. Hierbei handelt es sich meist um 6-Ziffern, die dem Benutzer via Mail oder SMS zugeschickt werden und ebenfalls beim Login eingegeben werden müssen. Oft werden OTP-Codes jedoch auch von Passwortmanagern verwaltet.

Keycloak spezifische Begriffe

• Realms
  Ein Realm ist die zentrale, isolierte Verwaltungseinheit in Keycloak. Man kann ihn sich als "Mandanten" mit klar voneinander getrennten Bereichen vorstellen. Jeder Realm verwaltet seine eigenen Benutzer, Clients, Rollen, Gruppen und Konfigurationen. Realms können die Inhalte anderer Realms nicht sehen und sind isoliert voneinander. Standardmäßig gibt es einen “master”-Realm, der der Administration dient und nicht für andere Zwecke genutzt werden sollte. Eigene Benutzer und Clients sollten in einem separat angelegten Realm abgelegt werden.
• Organizations
  Mandanten lassen sich in Keycloak insbesondere über eigene Realms abbilden, die eine strikte Trennung ermöglichen. Einige Geschäftsmodelle, insbesondere SaaS, verlangen einen starken Grad an Skalierbarkeit. Technisch stößt das Abbilden von sehr vielen Mandanten über immer neue Realms in Keycloak an seine Grenzen. Zudem werden Konfigurationen oft dupliziert, da sie dieselben Clients und Settings verwenden. Durch Organizations lassen sich in Keycloak Nutzer nach Organisationseinheiten gruppieren, wobei alle Nutzer die Settings und Clients eines Realms nutzen können. Die Isolation der Mandaten erfolgt hier lediglich über eine einfache Beziehung "Nutzer zu Organisation" und nicht so strikt wie bei der Trennung durch Realms.
• User Federation
  Standardmäßig werden Benutzer in der Keycloak-Datenbank gespeichert. Gerade im Unternehmenskontext kann es jedoch vorkommen, dass Benutzer in anderen Verzeichnissen (zum Beispiel Active Directory) bereits angelegt wurden und nicht mehrfach gepflegt werden sollen. Über User Federation lassen sich Benutzer aus diesen Verzeichnissen nach Keycloak synchronisieren.
• Identity Provider
  Eine weitere Quelle für extern gespeicherte Benutzer können Identity Provider sein, die über Protokolle wie OAuth/OIDC integriert werden können. Bei Identity Providern handelt es sich meist um einen sogenannten Social Login (“Sign In with Google”, “Sign in with Facebook”, etc.) bei dem der Benutzer einen bestehenden Account in einem anderen System zum Login verwenden kann. Hierbei wird beim Login nur für den Account, der sich gerade einloggt, ein Pendant in Keycloak angelegt, während bei User Federation alle Accounts der anderen Quelle übertragen werden.
• Required Actions
  Required Actions sind Aktionen, die ein Benutzer nach einer erfolgreichen Authentifizierung zwingend ausführen muss, bevor er vollen Zugriff auf die Anwendungen erhält. Hierüber kann man den Benutzer beispielsweise zwingen, sein Passwort zu aktualisieren, seine Profilinformationen zu prüfen oder aktualisierten AGB zuzustimmen.
• SPI Extension
  Das Service Provider Interface (SPI) ist die offizielle Plugin-Schnittstelle von Keycloak. Sie ermöglicht es Entwicklern, Keycloak mit eigenen, angepassten Funktionalitäten zu erweitern. Da Keycloak in Java implementiert ist, können Erweiterungen ebenfalls in Java implementiert werden. Extensions können überall dort zum Einsatz kommen, wo die Standardfunktionalität von Keycloak nicht ausreicht oder angepasst werden muss. Es existieren bereits eine Vielzahl von Open Source Keycloak-Erweiterungen, mit denen man einfach und schnell Keycloak mit Funktionen erweitern kann.