Wie Sie Keycloak-Realms intelligent planen: Dos und Don’ts
Wollen Sie Internetzugänge mit Keycloak implementieren, so kommen Sie um die Nutzung von „Realms“ nicht herum. Denn Keycloak-Architekten nutzen diese Begrifflichkeit, um Instanzen zu definieren und Zugänge zu planen. Realm bedeutet wortwörtlich „Reich“ oder „Königreich“. Davon sollte man nicht zu viele haben – in der realen Welt sowie auch in der Informatik.
Viele Realms erhöhen die Komplexität zu stark
Jeder Realm ist in Keycloak wie ein eigener Mandant, daher spricht man auch von Multi-Tenancy oder Mandantenfähigkeit. Daten und Konfigurationen werden darin gespeichert und sind für andere Realms nicht sichtbar.
Ein Realm besteht aus
- Nutzern
- Nutzergruppen
- sowie den zugeordneten Anwendungen, auf die Zugriff gewährt werden soll (Single-Sign-On).
- Rollen ergänzen das Modell – sie können entweder einer einzelnen Applikation oder einem gesamten Realm zugeordnet werden.
Hier ein Beispiel, damit es nicht zu abstrakt wird: Die weit verbreitete Atlassian-Software, welche Tools für Entwickler bereitstellt bedient sich verschiedener Rollen für ihre Benutzer. Zunächst ist nur eine Default-Rolle interessant, die es einem Nutzer nach seiner Registrierung erlaubt Zugang zu seinem Account zu erhalten. Soll dieser Login über Keycloak laufen, so muss diese einfache Rolle im Keycloak-Realm definiert sein.
Unter einer Anwendungsrolle versteht man einen Satz von Berechtigungen für die zugehörige Anwendung. Unter einer Gruppe können einzelne Rollen summiert sein und dabei stellt eine Gruppe einen Satz von Benutzern dar, die diese Rollen besitzen.
- Ein oder mehrere Identity Provider (IDPs) können auch dazu gehören, die direkt in einem oder mehreren Realms eingebunden werden können.
- Applikationen können meistens nur in einem Realm eingebunden werden. Um eine Applikation in mehreren Realms einzubinden, wird oft eine weitere Instanz dieser Applikation benötigt.
Der Master-Realm ist die Basis
Das Hinzufügen mehrer Realms sollte man gut überlegen und planen. Zunächst arbeitet man mit dem „Master Realm“, von diesem aus man die anderen Realms einstellt und steuert. Eine aussagekräftige Benennung des Realms, z.B. “Kunden” macht Sinn. Eine Nummerierung „Realm 1“, „Realm 2“ ist auch möglich.
Wie man einen Realm konfiguriert, findet man hier: Realms in Keycloak konfigurieren
Zum besseren Verständnis gibt es hier ein Schaubild, um das Ganze zu demonstrieren:
Schaubild: Ein Realm im Überblick
Nutzergruppierungen sind ein wichtiger Realm-Baustein in Keycloak
Verschiedene Nutzergruppen sind oft ein Grund dafür, mehrere Realms bei Keycloak einzusetzen. Häufig sieht man folgende Realms-Aufteilungen:
- Um nach Compliance-Kriterien zu trennen, zum Beispiel eine landesspezifische Realm-Einteilung (USA, EU, Asia-Pacific, …)
- Um nach unterschiedlichen Kunden, Nutzern oder Nutzergruppen (mit oder ohne eigenen Endnutzern) zu trennen; um zum Beispiel Daten und IDP-Konfigurationen voneinander zu isolieren.
- Um nach verschiedenen Nutzergruppen im Sinne von Gruppen mit unterschiedlichen Zugriffsrechten, z.B. Rollenkombinationen (Role based access control = RBAC) zu trennen.
- Um nach einem Set verschiedener Anwendungen zu trennen.
Das klingt zunächst einmal logisch, bringt aber eine gewisse Komplexität mit sich. Ineffizient wird es, wenn die Trennung insbesondere der Kundengruppen zu feingranular ist.
Warum sind mehrere Realms wenig zu empfehlen?
Keineswegs empfehlenswert ist es beispielsweise einen Realm pro Kunde anzulegen. Es werden zu viele, um das System noch performant betreiben zu können. Außerdem gibt es mit den derzeitigen Keycloak-Versionen einen Leistungseinbruch, wenn es in einer Instanz mehr als 300 Keycloak-Realms gibt. Erst mit dem neuen Speichermodell werden solche Hindernisse ausgeräumt; Produktionsreife wird dieses aber frühestens Ende des Jahres 2023 erreichen. Der Workaround hierfür sieht so aus: Bis dahin betreibt man multiple Keycloak-Instanzen.
Das bedeutet dann aber auch: Jede Instanz birgt eigene Sicherheitslücken, muss eigens konfiguriert und gewartet werden. Für jede Instanz sind Sicherheitspatches individuell einzuspielen. Es können Speicherprobleme auftreten. Durch die wachsende Komplexität geht schnell die Übersicht verloren und Fehler im Betrieb können sich einschleichen. Jeder Realm bedeutet eben eine eigene, abgeschlossene Einheit, auch wenn man versucht mit Automatisierung dagegen zu halten.
Die Nutzerlandschaft bestimmt die Komplexität der Keycloak-Realms
Die Komplexität ist schon da, weil diese durch die abzubildende Organisationsstruktur oder die Erfordernisse der Nutzergruppierungen bestimmt wird. Es gibt jedoch eine smarte Lösung für diese Mammut-Aufgabe: Das Berechtigungsframework SecuRole® vermeidet eine unnötige Realm-Vervielfachung.
Die benötigte Funktion zum Berechtigungsmanagement kommt aus dem internen IAM und sorgt für Klarheit in der Delegation und Zuteilung von Rollen für bestimmte Nutzer. Für Webanwendungen im externen IAM lässt sie sich leicht mit der oben genannten Keycloak-Erweiterung umsetzen. Dabei kann man sogar die Sicherheit und die Compliance im Zusammenspiel mit Identity Providern steigern. Wie das?
Wie gelingt eine Ende-zu-Ende-Sicherheit mit Keycloak?
Ein Beispiel mit Active Directory (AD) oder Azure zeigt, wie die Keycloak-Erweiterung SecuRole® eine Ende-zu-Ende-Sicherheit bringt:
Kommen Nutzer aus internen Quellen – zum Beispiel Vertriebsmitarbeiter, die Kunden betreuen – so werden diese aus AD-Gruppen in bestehende Keycloak-Gruppen übernommen. Da aber AD infrastrukturbezogen arbeitet und nichts mit IAM-Prozessen in diesem Sinne zu tun hat, geschieht das ohne digitale Signatur. Durch Einbau einer weiteren Sicherheitsebene mit dem Berechtigungsframework SecuRole® kann diese hinzugefügt werden, ohne auf AD oder Keycloak verzichten zu müssen oder ohne das ganze Konzept zu verlassen.
Weder Keycloak noch AD oder Azure gewährleisten eine Ende-zu-Ende-Sicherheit
Doch diese ist heutzutage unverzichtbar, gerade wenn die Anforderungen in Punkto IT-Sicherheit steigen und man von einer Legacy-Infrastruktur in die Cloud wechseln möchte. Wer diesen Punkt noch besser verstehen will, dem empfehle ich diesen Blogartikel bzw. den Kuppinger&Cole Analyst Chat zum Thema Active Directory:
Analyst Chat KC #77: Don’t Manage Access in Active Directory Groups
Blogartikel: Active Directory als der Teil der IAM-Stragie – wichtig, aber nicht ausreichend