Keycloak: Log-In und SSO machen noch kein IAM

Auf der Suche nach einem kostenfreien Tool für Authentifizierung und Single Signon (SSO) landen viele Entwickler bei Keycloak. Das Open-Source-Projekt erfreut sich seit 2016 wachsender Beliebtheit. Die von Red Hat gesponserte Software erlangte weltweit in kurzer Zeit eine große Community. Sie basiert auf modernen Standardprotokollen, wie OpenID Connect (OIDC) und SAML 2 (Security Assertion Markup Language)/OAUTH2. Es nutzt JSON Web Tokens zur Übertragung von Benutzer und Autorisierungsinformationen – auch hier also aktuelle Technik. Doch was kann dieses Tool tatsächlich – und was eben nicht?

Gebaut für die Authentifizierung von Nutzern an Webanwendungen hat sich Keycloak mittlerweile zu einem Allrounder für schnelle, skalierbare und sichere Anmeldungen im Netz gemausert. Das Tool bietet sich an, wenn es um die Integration von Clients (Webanwendungen) und Identity Providern geht. Zudem lässt es sich per SPIs (Service Provider Interfaces) einfach erweitern. Auch wenn die Software viele Funktionen mit sich bringt, bedarf es hier und da einer Anpassung oder Erweiterung für den eigenen Anwendungsfall. Auch das API (Application Programming Interface) gilt als gut ausgereift. Es tauscht Daten im Internet mit Anwendungen aus – streng genommen mit RESTful Webservices (REST = Representational State Transfer) auf Basis einer REST-API.

Die Skalierbarkeit im Kubernetes Cluster verspricht Vorteile in der Automatisierung, insbesondere beim Betrieb verschiedener Keycloak-Umgebungen. Auch wenn es um angepasstes Design für die Log-in-Masken im Frontend geht, kann das Tool punkten: Über User Interfaces (UIs) lässt sich die Navigationsoberfläche sehr einfach so modifizieren, dass sie zur Corporate Identity (CI) und zum Corporate Design (CD) der eigenen Firma passt. Und auch Whitelabeling ist mit Keycloak kein Problem.

Wo Keyloak Authentifizierungslösung Schwächen zeigt

Das Thema Identity und Access Management (IAM) ist für Webservices wichtiger und umfangreicher als von vielen angenommen. Denn es geht nicht nur um die bestmögliche Sicherheit von Nutzeraccounts, sondern auch um eine effiziente Pflege von Identitätsdaten. Themen wie Datenschutz-Grundverordnung (DS-GVO), Analysen über Nutzerverhalten oder die automatisierte Berechtigungsverwaltung sind heute nicht mehr wegzudenken, aber schwierig selbst zu implementieren. Denn dies sind größtenteils klassische IAM-Funktionen, die Keycloak nicht „Out of the box“ mit sich bringt. Weiteres Manko: Die Aufmachung des Open-Source-Tools suggeriert eine allumfassende Lösung, ein ganzheitliches IAM-System für alle Internetanwendungen. Doch dem ist nicht so. Selbst Red Hat reduziert seine Keycloak-Bezahlversion auf den reinen Einsatz zur Authentifizierung und preist sie nicht als Lösung für umfangreiche, IAM-bezogene „Business-Aufgaben“ an.^[1]

Diese Einschätzung deckt sich mit der Erfahrung von Experten. Zur Gewährleistung eines effizienten und sicheren Identitätsmanagements sind folgende Zusatzfunktionen oft unerlässlich:

• Registrierung und Migration von Nutzer(-konten), unterschieden nach Herkunftsquellen zur automatisierten Einordnung in verschiedene Berechtigungslevel
  Automatisierung, insbesondere im User-Life-Cycle-Management
• umfangreicher Benutzer-Self-Service zur Entlastung des Supports
• erweitertes, teilautomatisiertes Zugriffsrechtemanagement
• erweiterte Sicherheit und Skalierbarkeit von Berechtigungsstrukturen
• Abbildung von Organisations-, Projekt oder Kundenstrukturen zur Umsetzung delegierter Administration (Genehmigungs-)Workflows
• ein Metadirectoy und die Provisionierung von Legacy-Anwendungen zur Integration von Datenquellen
• Cloud-Kompatibilität
• unterstützende Services: professionelle/r IAM-/Keycloak-Beratung und -Support
• Das „Unwissen“ über die Defizite von Keycloak führt oft zu starken Projektverzögerungen und häufig zu halb fertigen, unsicheren Lösungen, welche Versuche von Eigenprogrammierungen provozieren.

Technische Fehler beim Einsatz von Keyloak

Nicht nur die Planung und Konzeption zum Einsatz des Open-Source-Tools stellt die Betreiber vor große Hürden. Auch technische Feinheiten lassen manche Entwickler hadern. Ein Beispiel hierfür ist das Aufsetzen mehrerer Realms, um Zugriffe auf mandantenbezogene Verzeichnisse voneinander zu trennen. Das kann mitunter höchst ineffizient werden, insbesondere, wenn die Mandantenzahl wächst. Für jede Instanz werden letztendlich Wartung und das Updaten zu einer singulären Aufgabe, wodurch sich diese Arbeit über alle existierenden Realms aufsummiert.

Auch die Supportlast erhöht sich dadurch stark. Die häufigsten Irrtümer beim Einsatz von Keycloak betreffen beispielsweise die fehlende Erweiterung der Log-in-Sicherheit durch Multi-Faktor-Authentifizierung. Bei der Infrastrukturplanung wird oft übersehen, dass Keycloak keinesfalls selbst zum Single Point of Failure werden sollte, soll es doch für mehr Sicherheit sorgen. Im Produktivbetrieb stellen sich weitere im Produkt nicht adressierte Anforderungen, die etwa Skalierbarkeit oder Hochverfügbarkeit mit einschließen.

Limits von Keycloak in der Praxis 

Die Community lobt an Keycloak besonders, dass die Integration von Webapplikationen durch die Standardprotokolle sehr schnell möglich ist. Zudem erlauben viele Programmteile eine einfache und schnelle Konfiguration. Ist der planerische Teil und die Konfigurationsarbeit erledigt, entpuppen sich in der Praxis weitere Fallstricke, die Keycloak von fertigen IAM-Lösungen für browserbasierte Anwendungen unterscheidet:

• Ein georedundanter Betrieb stellt sich aufwendig dar, da dies komplexe Setups erfordert. Keycloak unterstützt dies nur als „Preview“.
• Aktuell werden noch keine Zero-Downtime Deployments unterstützt. Bei Upgrades kann es in Abhängigkeit von Setup und Benutzermengen zu längeren Ausfallzeiten kommen.
• Es ist kein gemanagtes Container-Image verfügbar, welches den sicheren Betrieb, die Wartung und die Replikation von Keycloak-Umgebungen wesentlich vereinfachen würde.
• Obwohl von Red Hat entwickelt, sind die Konfiguration und das Management persistenter Sessions mit Infinispan kompliziert.
• Es gibt keinen out-of-the-box SCIM2-Support (System for Cross-Domain Identity Management). Dies wird besonders wichtig, wenn ein Identitätsdatenaustausch zwischen unterschiedlichen Cloud-Anwendungen oder -Services gefragt ist. Andernfalls kann Keycloak im Zusammenhang mit Identity Providern zu einer aus DS-GVO-Sicht bedenklichen Datensammelstelle werden.
• Das UI der Administratorkonsole ist nur für technisch versierte Nutzer oder Administratoren geeignet. Eine intuitive Bedienung durch eine nicht-technisch versierte Person ist kaum möglich. Diese Funktion bedarf einer gesonderten Programmierung, um insbesondere die Möglichkeiten für den 1st- und 2nd-Level-Support auszuweiten.

Fazit

Keycloak darf als ausgereifte Lösung zur Benutzerauthentifizierung und Single Sign-on bezeichnet werden. Durch die gute Unterstützung bestehender Standards lässt sich Keycloak einfach und schnell in Webapplikationen oder API-Backends integrieren. Ein zuverlässiger Betrieb birgt eigene Herausforderungen. Inzwischen gibt es am Markt aber erste Keycloak-as-a-Service-Anbieter, sodass Portalbetreiber auf eine Cloud zurückgreifen können, um Ressourcen einzusparen. Datenschutzrechtliche Anforderungen sind eigens zu evaluieren, zum Beispiel zur Datenspeicherung und Auditierung. Es können weitere Tools zur Verwaltung des Lifecycles der Identity- und der Berechtigungsobjekte notwendig sein.

Sie finden den Artikel auch im eMagazine der IT-SICHERHEIT 3/2022

_{Quellen
[1] https://access.redhat.com/announcements/2901111}