Keycloak

Identity und Access Management ist ein zentraler Baustein moderner Software-Architekturen. Eine weit verbreitete Open-Source-Lösung dafür ist Keycloak. Die Plattform ermöglicht Single Sign-On, Benutzerverwaltung und sichere Authentifizierung für Anwendungen.

Architektur

Keycloak Server

Der Keycloak Server ist die zentrale Laufzeitkomponente der Plattform. Er fungiert als Identity Provider und übernimmt sämtliche Aufgaben rund um Authentifizierung, Benutzerverwaltung und Token-Ausstellung.

Zu seinen zentralen Aufgaben gehören:

• Durchführung von Authentifizierungsprozessen mittels der Authorization Engine
• Verwaltung von Benutzern, Gruppen und Rollen
• Ausgabe und Signierung von Tokens
• Bereitstellung von Login-Flows und Sicherheitsrichtlinien in der Authentication Engine
• Integration externer Identity Provider
• Anbindung externer Benutzerverzeichnisse

Der Server stellt eine Reihe standardisierter Endpunkte bereit, die von Clients genutzt werden. Diese umfassen insbesondere:

• Authorization Endpoint
• Token Endpoint
• UserInfo Endpoint
• Logout Endpoint

Diese Endpunkte bilden die Grundlage für die Authentifizierungsflows gemäß SAML, OpenID Connect und OAuth 2.0.

Realm

Ein Realm ist die grundlegende organisatorische Einheit innerhalb von Keycloak. Er stellt eine logisch isolierte Sicherheitsdomäne dar, innerhalb derer sämtliche Identitäts- und Zugriffsinformationen verwaltet werden.

Ein Realm enthält typischerweise:

• Benutzer
• Rollen
• Gruppen
• Clients
• Authentifizierungsflows
• Identity Provider
• Sicherheitseinstellungen

Realms sind vollständig voneinander getrennt. Benutzer, Tokens oder Konfigurationen eines Realms sind nicht in anderen Realms sichtbar oder nutzbar.

Dieses Konzept erlaubt beispielsweise:

• Trennung verschiedener Anwendungen oder Plattformen
• Multi-Tenant-Setups
• getrennte Entwicklungs-, Test- und Produktionsumgebungen

Clients

Ein Client repräsentiert eine Anwendung oder einen Service, der Authentifizierung über Keycloak nutzt. Der Client möchte wissen wer der Nutzer ist (Authentifizierung) und vom Client die Berechtigung haben sich beim Resource Server informationen zu holen.

Typische Clients sind:

• Webanwendungen
• Mobile Anwendungen
• Single Page Applications
• Backend-Services
• APIs

Clients werden innerhalb eines Realms registriert und konfigurieren, wie die Anwendung mit Keycloak interagiert. Clients kommunizieren durch den Protocol Adapter mit dem Keycloak Server.

Resource Server

Der Resource Server stellt sensitive Daten bereit. Mittels Policy Enforcer redet er mit dem Keycloak Server um Autorisierungen und Policies durchzusetzen.

Storage Adapter

Keycloak bietet zu Entwicklungs und Testzwecken eine integrierte H2 Datenbank. Der Storage Adapter sorgt aber für eine agnostische Schnittstelle, sodass andere Datenbanken, wie Postgres oder MySQL, anzubinden.

Benutzerverwaltung

Innerhalb eines Realms verwaltet Keycloak Benutzeridentitäten. Ein Benutzer besitzt Attribute wie, welche über das Profil definiert werden. Typische Attribute sind:

• Benutzername
• E-Mail
• Passwort oder andere Credentials
• Rollen und Gruppen
• benutzerdefinierte Attribute

Zusätzlich können weitere Sicherheitsmechanismen aktiviert werden, beispielsweise:

• Multi-Factor Authentication
• Passwort-Policies
• Account-Locking
• Required Actions (z. B. Passwortänderung beim ersten Login)

Benutzer können direkt in Keycloak gespeichert oder über externe Systeme wie andere Identity Provider und User Federation bereitgestellt werden.

Gruppen

Gruppen sind eine organisatorische Struktur innerhalb eines Realms, die dazu dient, Benutzer logisch zu bündeln und Zugriffsrechte zentral zu verwalten. Sie ermöglichen es, Berechtigungen und Rollen nicht individuell jedem Benutzer zuzuweisen, sondern kollektiv auf eine Gruppe anzuwenden.

Jede Gruppe kann:

• Mitglieder (Benutzer) enthalten
• Rollen und Berechtigungen zugewiesen bekommen
• Verschachtelte Untergruppen besitzen, um komplexe Organisationsstrukturen abzubilden

Die Mitgliedschaft in einer Gruppe vererbt automatisch alle der Gruppe zugewiesenen Rollen und Berechtigungen an die enthaltenen Benutzer. Das vereinfacht das Management von Zugriffsrechten erheblich, besonders in größeren Umgebungen mit vielen Benutzern und differenzierten Berechtigungsanforderungen.

Typische Einsatzszenarien für Gruppen sind:

• Abbildung von Teams, Abteilungen oder Projektgruppen
• Rollenzuweisungen für gemeinsame Verantwortlichkeiten
• Steuerung von Zugriff auf Applikationen oder Ressourcen auf Basis der Gruppenzugehörigkeit

Durch die Kombination von Gruppen und Rollen kann Keycloak flexible und skalierbare Zugriffskonzepte realisieren, die sich an die organisatorischen Gegebenheiten von Unternehmen anpassen.

User Federation

Die User Federation ermöglicht die Integration externer Benutzerverzeichnisse in Keycloak.
Ein häufiges Szenario ist die Anbindung eines Unternehmensverzeichnisses über LDAP oder Active Directory.

In diesem Modell bleibt das externe System die primäre Quelle für Benutzerinformationen. Keycloak fungiert lediglich als Authentifizierungs- und Token-Service.

Je nach Konfiguration kann Keycloak:

• Benutzer dynamisch aus dem Verzeichnis lesen
• Benutzer lokal synchronisieren
• Authentifizierung an das externe System delegieren

Das erlaubt eine Integration in bestehende Identity-Infrastrukturen ohne Migration aller Benutzer in Keycloak.

Identity Provider

Neben der User Federation unterstützt Keycloak auch die Integration externer Identity Provider (IdP).

Dabei authentifiziert sich der Benutzer nicht direkt bei Keycloak, sondern bei einem externen Anbieter. Keycloak übernimmt anschließend die Identität und erstellt eine eigene Session.

Unterstützt werden verschiedene Protokolle und Anbieter, darunter:

• OpenID Connect
• SAML 2.0

Typische externe Anbieter sind beispielsweise:

• Google
• Microsoft

Diese Integration ermöglicht unter anderem:

• Social Login
• Enterprise Single Sign-On
• Föderation zwischen Organisationen

Keycloak als Open-Source-Lösung

Keycloak ist ein Open-Source- Identity- und Access-Management-System (IAM), das häufig für Single-Sign-On und Identity-Provider-Szenarien eingesetzt wird.

Ein wesentlicher Vorteil von Keycloak ist, dass es ohne Lizenzkosten betrieben werden kann. Als Community-getriebenes Open-Source-Projekt wird es kontinuierlich weiterentwickelt und kann vollständig selbst gehostet werden. Zudem lässt sich die Plattform durch Erweiterungen und Custom Provider stark anpassen.

Neben der Authentifizierung unterstützt Keycloak auch eine integrierte Authorization-Engine, mit der sich Zugriffsregeln zentral definieren lassen. Dadurch kann Keycloak nicht nur als Identity-Provider, sondern auch als Policy Decision Point für Zugriffskontrolle eingesetzt werden.

Alternativen zu Keycloak

Es existieren zahlreiche Alternativen zu Keycloak. Viele dieser Lösungen konzentrieren sich primär auf Authentifizierung und Token-Ausstellung, während komplexere Autorisierungslogik häufig in Anwendungen oder APIs implementiert wird.

Open-Source Alternativen

Beispiele für Open-Source-Identity-Provider sind ZITADEL oder authentik. Diese Systeme sind oft leichtergewichtig und moderner aufgebaut, fokussieren sich jedoch stärker auf die Rolle als Identity-Provider.

Cloud-basierte Identity-Provider

Kommerzielle Plattformen wie Auth0, Okta, Amazon Cognito oder Microsoft Entra ID bieten Identity-Services vollständig aus der Cloud an. Dadurch entfällt der Betrieb eigener Infrastruktur, allerdings entstehen Lizenz- oder Nutzungsgebühren.

Developer-First-Lösungen

Tools wie Logto oder SuperTokens richten sich speziell an Entwickler moderner Web- und Microservice-Architekturen. Sie stellen Identity-Funktionen primär über APIs bereit und lassen sich leicht in bestehende Anwendungen integrieren.

Red Hat Single Sign-On

Eine besondere Rolle spielt Red Hat Single Sign-On (RH-SSO). Dabei handelt es sich um eine Enterprise-Distribution von Keycloak, die von Red Hat gepflegt und unterstützt wird.

RH-SSO basiert technisch auf Keycloak, wird jedoch von Red Hat stabilisiert, getestet und mit kommerziellem Support sowie langfristigen Wartungszyklen angeboten. Unternehmen, die auf Support-Verträge oder zertifizierte Integrationen angewiesen sind, setzen daher häufig auf diese Variante.

Autorisierung

Keycloak bietet eine Reihe an mechanismen um Policies zu implementieren und durchzusetzen. Dabei können alle Autorisierungskonzepte implementiert werden.

Zur Autorisierung von Clients bietet Keycloak drei modelle an.

• Keine Autorisierung - Die meisten apps nutzen Keycloak lediglich als Identity Provider und ignorieren die Autorisierungsmöglichkeiten. Keycloak liefert dann nurnoch die Rolle im Token und Autorisierung erfolgt im Resource Server.
• Requesting Party Token (RPT) - Der Client (Requesting Party) fordert einen Token an, der sagt auf welcher Resource er welche Operation durchführen darf (z.B. POST auf /documents). Der Resource Server prüft dann nurnoch ob die aktuelle Operation auf der aktuellen Resource im RPT enthalten ist.
• Resource Server Seitig - Der Resource Server kann auch den Access Token selbst an Keycloak senden und prüfen ob der Client berechtigt ist. Technisch ist das das gleiche und der Resource Server würde einen RPT bekommen, interessiert sich aber nur für Erfolg (Autorisiert) oder Fehler (nicht Autorisiert).

Konzept

Ein Client (oder Resource Server) fragt mittels eines Access Tokens, Resource und Scope bei Keycloak an und bittet um einen RPT der bestätigt, dass der Client berechtigt ist die Aktien (Scope) auf die Resource durchzuführen

• Resource - ist ein Okjekt, auf das zugegriffen werden soll
• Scope - ist meist die Methode (Create, Read, Update, Delete, …), kann technisch aber jede feingranularere Untereinheit der Resource sein.
• Policy - stellen unabhängig von Resource und Scope Regeln auf ob ein Nutzer etwas darf. Dabei können Rollen, Attribute, Umgebungen, Zeit, Position, und vieles mehr in Betracht gezogen werden, um am Ende zu entscheiden ob ein Zugriff autorisiert ist oder nicht.
• Permissions - weisen Policies zu Resourcen und Scopes zu. Sie sagen “Zugriff ist genehmigt, wenn der Client auf Resource X Scope Y zugreifen will und Policy Z positiv ist”.

Nachteile

Der Policy enforcer ist zwar eine einfache möglichkeit schnell und flexibel Autorisierung in eine App zu bauen, bietet aber aufgrund der Zentralisierung einige Nachteile.

• Schlechte Skalierbarkeit - Aufgrund des Zentralen Enforcements bekommen Verteilte Systeme ein zentrales Bottleneck. Das schadet der Skalierbarkeit und der Verfügbarkeit. Ist also nicht für öffentliche SaaS geeignet.
• Komplexität - Wenn ein simples Rollenkonzept ausreicht ist das meist schneller im Backend implementiert, wenn das nur eine einzelne Abfrage ist.
• Verwaltungsaufwand - Jede Resource muss zentral angelegt und verwaltet werden. Wenn nutzer eigene Resourcen anlegen können, z.B. bei DAC, steigt der Verwaltungsaufwand von Keycloak exponentiell.
• Designaufwand - Meist ist Autorisierung stark mit dem Design des Backends gekoppelt. Eine Integration außerhalb, also in Keycloak erfordert zusätzlichen Aufwand für die Entkopplung.
• Latenz - Jede Anfrage ans Backend ist auch eine rekursive Anfrage an Keycloak. Bei starken Latenzanforderungen ist das ungeeignet
• Lernkruve - Wenn das Team die Integration nicht kennt, ist eine Backendseitige Implementierung meist ohnehin schneller
• Lock In - Wenn eine App Keycloak integriert muss sie auch immer mit Keycloak genutzt werden. Eine unabhängige Bereitstellung ist nicht mehr möglich. Das macht die Distribution der Anwendung schwer, weshalb Keycloak Autorisierung in (fast) keiner Anwendung verbaut ist.

[!TIP]
In ~95-99% aller Fälle ist die Integration von Keycloak als Autorisierungsengine langfristig ungeeignet. Allerdings ist es sehr gut geeignet für Proof of Concepts (PoCs) und Sicherheitskritischer Infrastruktur wo eine sichere, zentrale Policyverwaltung wichtiger ist als Latenz und verfügbarkeit. Da die wenigsten Internen Tools den Stand den PoC offiziell verlassen, lohnt es sich hier auch oft den Weg über Keycloak zu gehen.

Keycloak im Kontext des BSI-Grundschutzes

Innerhalb eines nach BSI-Grundschutz zertifizierten oder ausgerichteten IT-Systems übernimmt Keycloak eine zentrale Rolle im Bereich Identitäts- und Zugriffsmanagement (IAM).

Die Verwendung von Keycloak unterstützt dabei die Umsetzung mehrerer BSI-Anforderungen, unter anderem:

• Zugangskontrolle: Keycloak stellt sicher, dass nur autorisierte Benutzer Zugriff auf geschützte Anwendungen und Ressourcen erhalten.
• Authentifizierung und Autorisierung: Durch standardisierte Verfahren (z. B. OpenID Connect, OAuth 2.0) gewährleistet Keycloak sichere und nachvollziehbare Login-Prozesse.
• Rollen- und Rechtemanagement: Die granulare Zuweisung von Rollen und Gruppen entspricht den Vorgaben zur differenzierten Zugriffsbeschränkung.
• Protokollierung und Nachvollziehbarkeit: Keycloak kann Login- und Token-Transaktionen protokollieren, was eine Überwachung und Nachvollziehbarkeit von Zugriffen ermöglicht.
• Integration in bestehende Sicherheitsinfrastrukturen: Mit Funktionen wie User Federation und Identity Federation lässt sich Keycloak nahtlos an Verzeichnisdienste und externe Identity Provider anbinden, was den Betrieb in komplexen, sicherheitskritischen Umgebungen erleichtert.

Damit trägt Keycloak maßgeblich zur Einhaltung der Sicherheitsanforderungen des BSI-Grundschutzes bei und unterstützt Organisationen dabei, ihre IT-Landschaft sicher und regelkonform zu gestalten.