Wie implementiert man ein granulares Berechtigungskonzept für B2B-Organisationen mit hierarchischen Nutzerrollen auf API-Ebene?

Wir setzen für B2B-Szenarien auf eine Kombination aus Role-Based Access Control (RBAC) und Relationship-Based Access Control (ReBAC). Die Grundlage bildet eine Multi-Tenancy-Architektur, bei der jeder API-Request über einen JWT-Token eine eindeutige organization_id und eine user_id mitführt.

Um Granularität zu erreichen, trennen wir die Rolle (z. B. "Manager") von den tatsächlichen Berechtigungen (Permissions, z. B. invoice:read). Rollen fungieren lediglich als Container für Permission-Sets.

RollePermission-SetScopeZugriffsebene
Org-Admin*:*OrganisationGlobal (Tenant)
Regional-Leaduser:read, report:writeRegion/BranchHierarchisch untergeordnet
Operatororder:create, order:readEigene AbteilungFunktional begrenzt

Die technische Umsetzung auf API-Ebene erfolgt über einen dreistufigen Prozess:

  1. Policy Enforcement Point (PEP): Eine Middleware fängt den Request ab und extrahiert die Identität sowie die Zielressource.
  2. Policy Decision Point (PDP): Eine zentrale Logik prüft, ob die user_id im Kontext der organization_id die benötigte Permission besitzt. Bei hierarchischen Rollen wird geprüft, ob die Rolle des Nutzers eine übergeordnete Position in der Organisationsstruktur einnimmt (z. B. via Adjacency List oder Nested Sets in der Datenbank).
  3. Data Filtering: Die API-Query wird durch einen automatischen Filter ergänzt, der sicherstellt, dass nur Daten der eigenen Organisation oder der untergeordneten Hierarchieebenen zurückgegeben werden.

Die Konfiguration und Orchestrierung solcher Identitätsstrukturen ist ein Kernbestandteil unserer Arbeit im Bereich Cloud & Digital Workplace.

Für die Verwaltung der Hierarchien nutzen wir oft eine Graph-Datenstruktur oder spezialisierte Tabellen für die Vererbung, um tiefe Verschachtelungen ohne Performance-Einbußen abzubilden. Dies verhindert, dass die API-Logik mit komplexen IF-ELSE-Ketten überlastet wird.

Verzichten Sie auf eine hartcodierte Rollenprüfung in den Controllern; implementieren Sie stattdessen eine entkoppelte Policy-Engine (wie Open Policy Agent), um die Berechtigungslogik unabhängig vom Code zu versionieren und dynamisch an neue B2B-Kundenanforderungen anzupassen.

Sergej Wiens

Sergej Wiens

Gründer & Software Architekt