Keycloak – Ein Überblick
Ein Fachbeitrag von Tobias Surmann und Phillip Conrad aus dem Segment Finance & Public
Seiteninhalt
Einleitung
Durch die steigende Anzahl von Unternehmensdiensten, die ohne einen VPN-Zaun über das Internet erreichbar sein sollen, nimmt der Bedarf an webbasierten Identity & Access Management-Lösungen stetig zu. IAM-Lösungen und entsprechende Security-Protokolle ermöglichen es, solche Dienste über das „unsichere Medium“ Internet entsprechend abgesichert anzubieten. Keycloak ist eine IAM-Komponente, welche die Benutzeridentitäten samt den zugehörigen Zugriffsrechten (Authentifizierung sowie Autorisierung) für die angebundenen Anwendungen in Form eines Authentifizierungsgateway bereitstellt.
Bei Keycloak handelt es sich um eine Open Source Lösung, die entsprechend kostenlos verfügbar ist. Das Projekt existiert seit 2014, wird kontinuierlich weiterentwickelt und durch Red Hat begleitet. Keycloak bietet viele Features out-of-the-box, ohne dass dafür programmiert werden muss. Im einfachsten Fall kann man Keycloak inklusive Application-Server herunterladen, sofort starten und konfigurativ auf die eigenen Bedürfnisse anpassen.
Es ist auch möglich, sich über die vielen Erweiterungspunkte in Keycloak einzuklinken, um so mithilfe der Programmierung Einfluss auf das Verhalten von Keycloak zu nehmen oder Funktionsergänzungen durchzuführen. Wer direkten Herstellersupport benötigt, für den ist die kommerzielle Variante „Red Hat Single Sign-on“ eine Option. Dabei handelt es sich um einen älteren Versionsstand, der als gereift betrachtet werden kann.
Keycloak selbst wird unter der Lizenz „Apache License 2.0“ veröffentlicht. Diese Lizenz muss für unveränderte Teile der Software weiter mitgeliefert werden, für geänderte Teile lässt sich selbst eine Lizenz wählen – auch eine kommerzielle Verwertung ist hierbei nicht ausgeschlossen. Technisch setzt Keycloak auf Java-Technologien. Für den Betrieb wird seit der Version 17 Quarkus als Service-Stack empfohlen. Seit der Version 20 ist der cloud-native Ansatz von Quarkus fester Standard.
In den letzten Jahren haben wir von SMF zahlreiche IAM-Kundenprojekte auf Keycloak-Basis umgesetzt. Unsere Dienstleistungen umfassen unter anderem folgende Tätigkeiten:
Keycloak-Implementierungen
In der Cloud oder On-Premises, wir helfen, Ihre Keycloak-Instance aufzusetzen: ob Docker, Podman, Linux, Windows, Kubernetes, Single Host oder Cluster.
Integration in Systemlandschaft
Die Anbindung von Keycloak an Ihre vorhandenen Services stellt häufig das eigentliche Projekt dar. Wir helfen, Ihre Lösungen pass-genau an Keycloak anzubinden.
Keycloak-Entwicklungen
Entwicklung von Add-Ons/Erweiterungen für Keycloak. Abrundung des IDM/IAM-Prozesses durch die Anbindung von Workflow-basierten Lösung.
Features von Keycloak
Keycloak bringt eine Menge Features mit, die im Folgenden jeweils kurz beleuchtet werden.
Single Sign-on und Single Sign-out
Möchte man mehrere Applikationen oder Dienste verwenden, so sind in der Regel bei jeder Applikation separate Logins erforderlich. Beim Single Sign-on (SSO) geht es jedoch darum, dass nur eine einzige Authentifizierung notwendig ist (beim ersten Zugriff auf eine der Applikationen). Dies geschieht dadurch, dass die Applikation die Benutzerin bzw. den Benutzer auf eine zentrale Keycloak-Instanz weiterleitet, welche die Login-Maske für die angesprochene Applikation ausgibt und in der Folge die Authentifizierung durchführt.
Nach erfolgreicher Anmeldung wird zur Applikation weitergeleitet. Werden anschließend andere Software-Systeme im SSO-Verbund verwendet, dann weiß Keycloak, dass die Benutzerin bzw. der Benutzer bereits authentifiziert ist und fordert keine weitere Anmeldung mehr. Zusätzlich verfügt Keycloak auch über eine Kerberos-Bridge, sodass die Anmeldung am Arbeitsrechner für die Authentifizierung ausreicht. Darüber hinaus unterstützt Keycloak auch ein Single Sign-out: Nach der Abmeldung erfolgt das automatische Ausloggen aus allen Applikationen im SSO-Verbund.
Unterstützung von Standardprotokollen
Keycloak unterstützt Standardprotokolle wie OAuth 2.0 (nur Autorisierung) und das darauf basierende OpenID Connect (Autorisierung und Authentifizierung). Daneben wird mit SAML 2.0 ein weiteres Standardprotokoll unterstützt, das ähnliche Anforderungen wie OpenID Connect (OIDC) abdeckt. Im Gegensatz zu OIDC existiert SAML jedoch schon länger, basiert auf XML und setzt zum Erreichen von Integrität und Vertraulichkeit digitale Signaturen und entsprechende Zertifikate ein.
Self-Service-Portal für die Benutzer (Account Management Console)
Ein Self-Service-Portal ermöglicht es Benutzern, ihre Daten jederzeit selbst zu verwalten. Keycloak bietet ein solches Portal unter dem Namen „Account Management Console“ an. So können z. B. Passwortänderungen selbständig durchgeführt werden, ohne von Administratoren abhängig zu sein.
Darüber hinaus bietet das Portal eine Übersicht über alle Applikationen, die verwenden werdet können – nebst den Rollen, mit denen die Benutzer ausgestattet sind. Eine weitere Übersicht zeigt, in welchen Applikationen aktuell Sitzungen offen sind (inkl. Sitzungsmetadaten wie z. B. Start- und Ablaufdatum sowie Datum/Uhrzeit des letzten Zugriffs). Ist das Konto im Kontext von Social Logins mit anderen Diensten wie z. B. Google verknüpft, dann wird zusätzlich eine Seite zur Verwaltung föderierter Identitäten sichtbar.
Abgerundet wird das Self-Service-Portal durch die Option, eine Mehrfaktorauthentifizierung einzurichten. So werden Logins z. B. zusätzlich mittels One-Time-Pads (OTP) abgesichert. Dafür sind ein Smartphone und eine App notwendig, die QR-Codes lesen und auf dieser Basis OTPs generieren kann. Aktuell unterstützt Keycloak zu diesem Zweck die mobilen Apps FreeOTP und Google Authenticator.
Ein wichtiger Aspekt ist die Möglichkeit zur Konfiguration einer Keycloak-Instanz über ein zentrales, webbasiertes Interface. Diese wird in Keycloak „Admin Console“ genannt. Diese ermöglicht auch die Verwaltung zentraler Entitäten wie z. B. Benutzer und Rollen.
Die Admin Console umfasst im Wesentlichen die Konfiguration von:
- Realms (jeweils abgegrenzte Bereiche, für die die anderen in dieser Aufzählung genannten Aspekte einzeln konfiguriert bzw. verwaltet werden können)
- Clients (Applikationen und Dienste)
- Benutzerdatenquellen (siehe User Federation)
- weiteren Identity Providern (siehe Identity Brokering und Social Login)
- die Verwaltung von lokal in Keycloak angelegten Benutzern, Benutzern aus anderen Datenquellen, Benutzergruppen und Rollen
User Federation
Neben den lokal in Keycloak verwalteten Benutzern unterstützt Keycloak auch die Anbindung externer Benutzerdatenquellen. Somit können auch bereits vorhandene Datentöpfe genutzt werden, die Benutzerdaten enthalten.. Keycloak bietet beim Zugriff auf solch föderierte Datenquellen standardmäßig User Storage Provider für LDAP oder Active Directory an. Andere Arten von Datenquellen, wie z. B. relationale DBMS, können durch Implementierung eines eigenen Providers für das User Storage SPI (Service Programming Interface) angebunden werden.
In der Regel ist nur ein Ausschnitt an Attributen aus externen Benutzerdaten für Keycloak relevant. Hierfür kann in Keycloak ein Mapping angegeben werden. Passwörter verbleiben immer im Provider. Authentifizierungsanfragen werden daher immer an die eingebundenen User Storage Provider weitergegeben. Bei der Authentifizierung sucht Keycloak die Benutzerin bzw. den Benutzer immer zuerst in der lokalen Datenbank. Werden sie hier nicht gefunden, dann werden die einzelnen User Storage Provider in der konfigurierten Reihenfolge angesprochen.
Identity Brokering und Social Login
Keycloak kann auch als Identity Broker agieren und Authentifizierungsanfragen an externe Identity Provider IdPs delegieren. Ein IdP ist ein Dienst, der Benutzer authentifiziert. Hierbei werden Standardprotokolle wie OIDC oder SAML benutzt. Social Logins sind in Keycloak vorkonfigurierte bekannte IdP-Dienste wie z. B. Facebook, Google, Twitter u. v. m. Auf diese Weise wird zugelassen, dass sich Benutzer mit ihren Accounts externer Dienste registrieren bzw. einloggen.
Themes
Keycloak stellt für verschieden Prozesse, die im Rahmen eines Identity- & Access-Managements benötigt werden, entsprechende Eingabemasken zur Verfügung. Dazu gehören beispielsweise die Masken für den Registrierungsprozess sowie die Login-Maske, aber auch die Benutzungsoberflächen der Account Management Console oder der Admin Console. All diese Bereiche können mittels Themes optisch angepasst werden. Für jeden Client kann bei Bedarf ein eigenes Theme zum Einsatz kommen. Dies ist beispielsweise für die nahtlose Integration von Legacy-Anwendungen interessant. Technisch basieren die Themes auf FreeMarker-Templates.
Client-Adapter
Clients kommunizieren über die angebotenen Standardprotokolle mit Keycloak. Damit diese Kommunikation nicht für jeden Client – evtl. sogar redundant – selbst implementiert werden muss, gibt es für eine Vielzahl an Technologien und Frameworks fertige Client-Adapter, die sich einfach in die eigene Anwendung integrieren lassen und die Kommunikation mit Keycloak übernehmen. Für Spring-basierte Java-Anwendungen existiert etwa ein eigener Spring Boot Starter für Keycloak, der Adapter muss dazu nur noch mit einer JSON-Datei konfiguriert werden. Da ohnehin eine zugehörige Client-Konfiguration in Keycloak hinterlegt sein muss, lässt sich diese als Vorlage in Form einer entsprechenden JSON-Konfigurationsdatei aus der Admin Console herunterladen.
Clustering für Skalierbarkeit und Hochverfügbarkeit
Da Keycloak als IAM-System eine zentrale Komponente in der IT-Infrastruktur darstellt, ist es einer hohen Anzahl von Anfragen ausgesetzt. Damit stellt sich auch die Frage nach der Skalierbarkeit und Hochverfügbarkeit: Keycloak kann im Cluster betrieben werden. Auf technischer Ebene bilden JGroups und Infinispan das Rückgrat. JGroups ist ein Toolkit für die zuverlässige Kommunikation zwischen Clustern und Nodes während Infinispan als verteilter In-Memory-Cache für die Replizierung von Änderungen an Usern, Sessions, Realms etc. in Richtung aller Keycloak-Instanzen im Cluster verantwortlich ist.
Erweiterbarkeit von Keycloak
Keycloak bietet eine große Anzahl an Anknüpfungspunkten, über die sich neue Funktionalität anbinden oder bestehendes Verhalten abändern lässt. Hierzu sind in Keycloak auf Programmebene eine Vielzahl von Service-Provider-Interfaces (SPIs) vorgesehen, welche von Software-Entwickler*innen durch selbstentwickelte Plugins zur Erweiterung genutzt werden können. An dieser Stelle möchten wir einen Überblick über die wichtigsten SPIs geben:
Themes/Templates SPI: Standardmäßig können die Ansichten von Keycloak über Freemarker-Templates angepasst werden. Wenn ein weitergehendes Customizing erforderlich ist, kann über die Theme Ressource SPI oder die Theme Selector SPI erweitert werden.
Identity Brokering API: Keycloak kann Authentisierungsanfragen an andere Identity-Provider zwecks des beschriebenen Identity Brokerings weiterleiten. Falls die Menge an standardmäßig unterstützten Providern (Google, Microsoft, Facebook, GitHub usw.) nicht ausreichend sein sollte, dann können weitere IdPs auf Basis der Identity Brokering API ergänzt werden. Die Klasse „AbstractIdentityProvider“ kann dabei helfen.
Authentication SPI: Die Auswahl an verfügbaren Mehrfaktorverfahren ist groß und der Bedarf an abgeänderten Authentifizierungsverfahren beim Login wiederkehrend. Über die Authentication SPI ist es beispielsweise möglich andere Hardware-Tokens (RSA, Yubico) in die Login-Challenge einzubauen. Ebenfalls können in Abhängigkeit von einer Netzwerkzone einfache oder komplettere Authentisierungsabläufe (Flows) z. B. durch die Definition zusätzlicher RequiredActions entwickelt werden.
User Storage SPI: In einem ganzheitlichen Identity-and-Accessmanagement-Konzept ist der User-Directory-Service eine zentrale Komponente. Häufig sind solche Strukturen bereits in Form eines AD/LDAP-Verzeichnisses oder einer relationalen Datenbank – unabhängig von Keycloak – vorhanden. Diese Unabhängigkeit kann sinnvoll sein (vgl. Single-Responsibility Principle). Über die User Storage SPI kann ein solcher externer Verzeichnisdienst an Keycloak angebunden verwenden. Dies kann immer dann relevant werden, wenn der eingebaute LDAP-Provider nicht ausreichend ist.
Welche Möglichkeiten im Detail durch die SPIs geboten werden, klärt ein Blick in den Quellcode sowie die Dokumentationen von Keycloak. Generell implementiert jede SPI in Form des Factory-Patterns einen Service-Provider. Ein weiterer wichtiger Aspekt im Zusammenhang mit der Anpassung und Erweiterung von Keycloak ist der eingesetzte Technologie-Stack. Da Keycloak auf Frameworks und Technologien setzt, die weithin bekannt sind und sich in der Entwicklergemeinde etabliert haben, finden sich Entwicklerinnen und Entwickler gut zu recht.
Fazit: Darum ist Keycloak empfehlenswert
Keycloak deckt aktuell bereits viele Standardanforderungen an ein IAM-System ab und lässt sich umfangreich konfigurieren. Erweiterungsmöglichkeiten sind an vielen Stellen gegeben und die Dokumentation ist sehr detailliert. Da sich das System einer hohen Beliebtheit erfreut, finden sich auch viele Informationen und Lösungsansätze zu bekannten Herausforderungen im Netz.
Die Installation und Inbetriebnahme ist in mehreren Varianten möglich (z. B. mittels Docker-Containern), sehr einfach durchzuführen und lädt zum Experimentieren mit der Software ein. Ein nicht zu unterschätzender Aspekt ist zudem die lebendige Entwickler-Community, die einerseits für einen hohen Sicherheitsstandard sorgt und andererseits eine kontinuierliche Weiterentwicklung der Software sicherstellt. Patch-Versionen werden gewöhnlich in regelmäßigen Intervallen von wenigen Wochen veröffentlicht.
Bei weiteren Fragen rund um Keycloak kontaktieren Sie uns gern.
Phillip Conrad
Ihr Ansprechpartner zum Thema Keycloak
p.conrad@smf.de
Weiterführende Links
