In modernen, schnell wachsenden Systemlandschaften können Authentifizierungs-Strukturen schnell unübersichtlich werden. Das wird vor allem dann problematisch, wenn gesetzliche Vorgaben eingehalten und regelmäßige Audits durchgeführt werden müssen.

Die Rollen- und Rechte-Verwaltung, als Teil des ganzheitlichen Identity & Access Managements, sollte kein notwendiges Übel darstellen. Bereits während der Anforderungsanalyse können die anwendungsspezifischen Basisrechte definiert und notwendige Rollen entworfen werden.

Ich möchte euch in diesem Beitrag zeigen, wie diese Rollen und Rechte auf konzeptioneller Ebene strukturiert werden können. Die folgenden Punkte schauen wir uns dafür an:

1. Autorisierung als "Afterthought" ist problematisch
2. Was ist Role-Based Access Control (RBAC)?
3. Anwendungsfälle für RBAC
4. Grenzen von RBAC
5. Skalierbares RBAC-Design auf konzeptioneller Ebene
6. Standardisierte Bezeichner / Namensschema

Im nächsten Beitrag schauen wir uns dann an, wie wir dieses Konzept in Keycloak implementieren können. Am Ende des Beitrags findet ihr außerdem verschiedene Kontaktmöglichkeiten. Schreibt mir gern, wenn ihr euch austauschen wollt oder Fragen habt 😊

Autorisierung als "Afterthought" ist problematisch

Bei der Entwicklung neuer Enterprise-Software müssen die Anforderungen an die Autorisierung von Anfang an eine zentrale Rolle spielen. Das Thema darf nicht erst dann in den Fokus rücken, wenn die fachlichen Anforderungen implementiert sind und jetzt "nur noch die Authentifizierung und Autorisierung fehlt".

Vor allem wenn der Code für jeden neuen organisatorischen Anwendungsfall angepasst werden muss, ist die Autorisierung nicht professionell umgesetzt. Die Probleme beginnen meist dann, wenn folgende Abfragen im Code zu finden sind:
if (user.getRoles().contains("customer_manager")) { deleteCustomer(1234); }

Dieses Vorgehen verbindet die Organisationsstruktur mit der Autorisierung innerhalb einer Anwendung auf der technischen Ebene. Wenn die Fachabteilung entscheidet, dass künftig auch ausgewählte Mitarbeiter aus dem Support diese Funktion nutzen sollen, muss der Quellcode angepasst, getestet und veröffentlicht werden.

In einer sauberen Architektur wird die Organisationsstruktur von der technischen Autorisierung getrennt. Die Anwendung kennt keine Abteilungen, Hierarchien oder Business-Rollen. Sie kennt ausschließlich die anwendungsspezifischen technischen Aktionen. Diese Aktionen werden Basisrechte genannt. Wie diese Basisrechte an die Mitarbeiter der Organisation verteilt werden, ist nicht das Problem der Anwendung. Darüber hinaus können die notwendigen Basisrechte bereits im Rahmen der Anforderungsanalyse modelliert werden. Auf diese Weise ist die Autorisierung von Anfang an ein zentraler Aspekt neuer Anwendungen.

Was ist Role-Based Access Control (RBAC)?

Das grundlegende Ziel von RBAC ist simpel: wir definieren anwendungsspezifische Basisrechte, bündeln diese Rechte in angemessen Rollen und weisen den Nutzern eine Rolle oder eine Menge von Rollen zu. Die Entscheidung darüber, ob ein Nutzer innerhalb eines Systems Zugriff auf bestimmte Funktionalitäten hat, wird anschließend anhand der zugewiesenen Rollen bzw. anhand der durch die Rollen gebündelten Basisrechte getroffen.

Die Rollen selbst können hierbei ganz individuell auf die Bedürfnisse der Organisation zugeschnitten werden. Wichtig ist an dieser Stelle nicht unbedingt, wie die Rollen geschnitten werden. Vielmehr geht es darum, die Vorgaben zu dokumentieren und organisationsweit konsistent umzusetzen. Eine Rolle kann beispielsweise bestimmte Qualifikationen, die Zugehörigkeit zu einem Team oder einer Abteilung oder einen bestimmten Aufgabenbereich repräsentieren.

Wichtig hierbei ist, dass es Rollen geben kann, die sich gegenseitig ausschließen. Ein Mitarbeiter, der berechtigt ist, Lieferungen anzunehmen, darf vermutlich nicht die Vollständigkeit der Lieferungen bestätigen. Es muss innerhalb der Organisation Kontrollmechanismen geben, die in regelmäßigen Abständen sicherstellen, dass kein Mitarbeiter eine solche Rollenkombination besitzt. Das zugrundeliegende Konzept nennt sich "Separation of Duties". Die Implementierung solcher Mechanismen ist notwendig, um Betrug vorzubeugen.

Anwendungsfälle für RBAC

RBAC ist vor allem dann geeignet, wenn Zugriffsrechte an die Strukturen der Organisation und an klar definierte Geschäftsprozesse mit eindeutigen Aufgabenbereichen gebunden sind. Das Konzept ist hervorragend für grob- bis mittelgranulare Autorisierungen nutzbar.

Entkopplung von Code und Organisationsstrukturen
RBAC ermöglicht die Trennung von Code und den Strukturen innerhalb einer Organisation. Anwendungen müssen nicht wissen, welche Rolle ein Nutzer hat oder in welcher Abteilung er arbeitet. Sie prüfen ausschließlich die anwendungsspezifisch definierten Basisrechte. Anhand dieser Basisrechte wird der Zugriff autorisiert. Über welche Rollen der Nutzer die Basisrechte erlangt, welche Attribute der Nutzer besitzt oder was er außerhalb des Systems darf, ist für die Anwendung an dieser Stelle irrelevant.

Effiziente Skalierung der Rechte-Zuweisung
Ohne RBAC wächst der administrative Aufwand exponentiell. Jedem einzelnen Nutzer müssten für jede angebundene Anwendung die notwendigen Basisrechte zugewiesen werden, damit er seine Arbeit korrekt erledigen kann. Durch die zusätzliche Abstraktionsebene, die RBAC mit sich bringt, wird die Komplexität erheblich reduziert. Basisrechte werden logischen Profilen (Rollen) zugeordnet. Diese wiederum werden anschließend den Nutzern zugewiesen. Die Anzahl notwendiger Zuweisungen wird auf diese Weise reduziert und die Skalierbarkeit des Ansatzes verbessert sich. Darüber hinaus, wird durch dieses Vorgehen zum einen der administrative Aufwand verringert und zum anderen mögliche Fehlerquellen minimiert.

Governance und Compliance
Eine zentrale Anforderung von Security-Audits und Standards wie der ISO 27001 ist die lückenlose Nachvollziehbarkeit von Zugriffsrechten. Durch RBAC kann übersichtlich und nachvollziehbar dokumentiert werden, welche Nutzergruppen die Möglichkeit haben, auf kritische Systeme oder sensible Daten zuzugreifen. Eine solche Übersicht ist die Grundlage, um regulatorische Vorgaben zu erfüllen.

Grenzen von RBAC

Die Grenzen von RBAC werden vor allem im Kontext dynamisch zu treffender Entscheidungen sichtbar. Sobald auf der Ebene einzelner Datensätze entschieden werden muss, ob ein Nutzer autorisiert ist, spezifische Aktionen durchzuführen, wird reines RBAC schnell zum Anti-Pattern. Es gibt drei wesentliche Limitierungen.

Rollenexplosion
Sobald die notwendigen Berechtigungen für eine Anwendung zu feingranular werden, wächst die Anzahl benötigter Rollen massiv. Wenn eine Anwendung abbilden muss, dass ein Mitarbeiter nur die Rechnungen aus Deutschland mit dem Status "nicht freigegeben" bearbeiten darf, entsteht eine kleine, sehr spezielle Rolle. Die Wahrscheinlichkeit, dass die Anwendung vieler solcher Rollen benötigt, ist hoch. Die Organisation wird mit Rollen überflutet und der administrative Aufwand wächst.

Kein dynamischer Kontext
RBAC ist statisch. Sowohl die Rollen, als auch die gebündelten Basisrechte stehen fest. Umgebungsfaktoren können nicht ausgewertet werden. Eine Regel wie "Rechnungen dürfen nur während der Geschäftszeiten freigegeben werden", lässt sich mit Rollen nicht sauber abbilden.

Keine Ownership-Prüfung
Eine häufige Frage innerhalb von Anwendungen ist es, ob ein Nutzer autorisiert ist, eine spezifische Ressource zu löschen. Die Antwort könnte lauten: "Ja, wenn er der Ersteller (Owner) der Ressource ist." RBAC kennt diese Beziehung zwischen dem Nutzer und der Ressource nicht.

Sobald eine Anwendung kontextabhängige oder datensatzbasierte Autorisierungs-Entscheidungen treffen muss, reicht RBAC nicht mehr aus. Das Autorisierungs-Konzept müsste dann um ABAC (Attribute-Based Access Control), ReBAC (Relationship-Based Access Control) oder explizite Ownership-Prüfungen direkt in der Geschäftslogik erweitert werden. RBAC liefert in diesem Fall nur die Information darüber, ob der Nutzer generell berechtigt ist, diese Art der Ressource (bspw. Dokumente) zu löschen. Die finale Entscheidung zu der konkreten Ressource wird dynamisch anhand von Attributen oder Beziehungen getroffen.

Skalierbares RBAC-Design auf konzeptioneller Ebene

Um ein vollständiges RBAC-System zu modellieren benötigen wir vier Bausteine.

1. Basisrecht: definiert eine anwendungsspezifische Berechtigung.
2. Basisrolle: definiert eine anwendungsspezifische Rolle, die ein Basisrecht oder mehrere Basisrechte enthält.
3. Lokales Berechtigungsprofil: definiert ein anwendungsspezifisches Berechtigungsprofil. Dieses Profil besteht aus mindestens einer Basisrolle oder mehreren Basisrollen. Ein lokales Berechtigungsprofil wird durch eine Rolle repräsentiert, die wie oben angegeben, bspw. qualifikationsbezogen, aufgabenbezogen oder zugehörigkeitsbezogen zugeschnitten werden kann.
4. Globales Berechtigungsprofil: definiert das organisationsweite Berechtigungsprofil. Es enthält alle zugehörigen lokalen Berechtigungsprofile der Systeme, auf die ein Mitarbeiter mit dieser Rolle Zugriff haben soll. Ein globales Berechtigungsprofil ist i.d.R. genau so zugeschnitten, wie die lokalen Berechtigungsprofile, die durch das globale Profil gebündelt werden sollen.

Die folgende Abbildung visualisiert das Zusammenspiel dieser vier Bausteine.

Durch diese Architektur haben wir den großen Vorteil, dass neuen Mitarbeitern nur eine einzige Rolle zugewiesen werden muss (das globale Berechtigungsprofil). Eine einzige Zuweisung sorgt also dafür, dass der Mitarbeiter die Basisrechte aller Anwendungen erhält, die er für die Erledigung seiner Aufgaben benötigt.

Darüber hinaus werden in den Anwendungen selbst, nur die Basisrechte verwendet, um den Zugriff auf die entsprechenden Funktionalitäten zu autorisieren. Die Anwendungen müssen unsere gesamte Rollenarchitektur nicht kennen. Sie arbeiten ausschließlich auf ihren eigenen anwendungsspezifischen Basisrechten. Die Access Tokens, die durch den Authorization Server (AS) ausgestellt werden, enthalten nur die Basisrechte, die dem Nutzer auf Grundlage des Berechtigungsprofils zugewiesen wurden. Wie das technisch funktioniert und worauf dabei geachtet werden muss, schauen wir uns im nächsten Beitrag anhand von Keycloak als AS an.

An dieser Stelle sei noch einmal erwähnt, dass auf diese Weise, die Basisberechtigungen vergeben werden, die sich selten ändern. RBAC ist nicht für jeden Anwendungsfall ausreichend, bildet aber eine solide Grundlage. Sobald Berechtigungsprüfungen dynamisch oder attributbezogen erfolgen müssen, benötigen wir Konzepte wie ABAC oder ReBAC.

Standardisierte Bezeichner / Namensschema

Damit unser System auch bei zahlreichen Anwendungen übersichtlich bleibt, sind standardisierte Bezeichner Pflicht.

Basisrechte

Basisrechte sind in jedem Fall anwendungsspezifisch. Sie bestehen deshalb aus mindestens vier Bestandteilen. Diese sind:

1. Organisations-ID
2. Service-ID
3. Ressource, mit der gearbeitet wird
4. Aktion, die durchgeführt werden soll

Zusammengesetzt sieht der Bezeichner eines Basisrechts so aus:<organization_id:service_id:resource:action>

Die Organisations-ID sorgt dafür, dass wir Keycloak-spezifische Rollen von unseren Rollen unterscheiden können. Die Service-ID sorgt dafür, dass wir die Basisrechte über ihre Bezeichner direkt einem Service zuordnen können. Das hilft uns später in der Keycloak UI, wenn wir spezifische Basisrechte einer Anwendung suchen. Es kann nämlich durchaus sein, dass mehrere Anwendungen ein Basisrecht book_read definieren. In diesem Fall hilft uns die Service-ID bei der korrekten Zuordnung. Ein konkretes Basisrecht könnte demnach so aussehen:
lib:bsm:book:read

Unsere Organisation heißt in diesem Beispiel Library und hat die Organisations-ID lib. Wir erstellen ein Basisrecht book_read für unseren book-store-management-service mit der Service-ID bsm.

Basisrollen

Die Bezeichner für Basisrollen enthalten ebenfalls die

1. Organisations-ID und die
2. Service-ID.

Als Suffix verwenden wir role und eine laufende Nummer. Die Bedeutung der Rolle gehört in die Beschreibung der Rolle. Auf diese Weise bringen wir keine organisations-spezifischen Begriffe in den Bezeichner einer Basisrolle. Diese Begriffe können sich nämlich ändern. Bei einer Restrukturierung der Organisation müssen wir dann ggf. nur die Beschreibung und nicht die komplette Basisrolle anpassen. Der Bezeichner einer Basisrolle folgt dem Muster:
<organization_id:service_id:role_nr>

Eine Basisrolle in unserem book-store-management-service kann so aussehen:
lib:bsm:role_1 (book reader)

In den Klammern steht die Beschreibung der Rolle, die in Keycloak in einem separaten Feld eingetragen werden kann.

Lokale Berechtigungsprofile

Lokale Berechtigungsprofile bündeln eine oder mehrere Basisrollen. Es handelt sich also um eine zusammengesetzte Rolle. Der Bezeichner eines lokalen Berechtigungsprofils folgt dem Muster der Basisrollen. Der einzige Unterschied besteht darin, dass wir den Suffix comp_role anstelle von role nutzen. comp_role steht dabei für Composite Role - also für eine zusammengesetzt Rolle. Auch an dieser Stelle wollen wir keine Begrifflichkeiten aus der Organisation im Bezeichner des Berechtigungsprofils. Diese Informationen gehören ebenfalls in die Beschreibung. Der Bezeichner folgt also dem Muster:
<organization_id:service_id:comp_role_nr>

Ein lokales Berechtigungsprofil in unserem book-store-management-service kann so aussehen:
lib:bsm:comp_role_1 (Bibliothekar).

Globale Berechtigungsprofile

Das globale Berechtigungsprofil bündelt die korrespondierenden lokalen Berechtigungsprofile. Bei einem globalen Profil haben wir dementsprechend keinen Anwendungsbezug mehr. Die Service-ID entfällt somit. Repräsentiert werden diese Berechtigungsprofile durch Gruppen, denen Nutzer zugeordnet werden. Durch die Zugehörigkeit zu einer solchen Gruppe, erlangt der Nutzer alle Basisrechte der Gruppe.

Folgende Bestandteile enthält der Bezeichner eines globalen Berechtigungsprofils:

1. Organisations-ID
2. Suffix comp_role
3. Laufende Nummer

Der Bezeichner folgt also dem Muster:
<organization_id:comp_role_nr>

Ein globales Berechtigungsprofil unserer Library-Organisation kann so aussehen:
lib:comp_role_1 (Bibliothekar).

Der nächste Beitrag enthält eine praktische Umsetzung dieser Struktur in Keycloak. Auf diese werden die Konzepte verdeutlicht und greifbar. Ihr findet den Beitrag unter folgendem Link: https://www.nicokuchling.de/skalierbares-rbac-mit-keycloak/

Solltet ihr dennoch Fragen haben, kontaktiert mich gerne auf einem der folgenden Kanäle 😊

Let's Connect

Wie ihr sicher wisst, gibt es in der Softwareentwicklung nicht den einen, richtigen Weg. Softwareentwicklung lebt von zahlreichen Ideen und offenem Austausch.

Also schreibt mir ne Mail oder kontaktiert mich auf Instagram/LinkedIn 🤓

• LinkedIn: https://www.linkedin.com/in/nicokuchling/
• Instagram: @nicokuchling
• Mail: kontakt@nicokuchling.de