wiki/b-reference/platform/rbac.md

RBAC-System

Überblick

Das Role-Based Access Control bündelt Berechtigungen in Access Rules pro Rollenlabel und Kontext (DATA, UI, RESOURCE). Auswertung erfolgt zentral über interfaceRbac.py; Zielbild laut Architekturdokumentation: möglichst filternd in der Datenbank statt voller Tabellen-Scans in Python. Nutzer können mehrere Rollenlabels gleichzeitig tragen; die effektive Berechtigung entsteht aus Öffnungslogik (Union) über alle Rollen.

Zwei getrennte Rollensysteme

	Mandantenrollen	Feature-Instanz-Rollen
Labels (Beispiele)	admin, user, viewer	workspace-admin, workspace-user, workspace-viewer, feature-spezifisch
Scope	mandateId	mandateId + featureCode + featureInstanceId
Zuordnung	UserMandateRole	FeatureAccessRole

Invariante: Mandantenrollen und Feature-Instanz-Rollen nicht vermischen — kein Zuweisen eines Mandanten-Labels zu FeatureAccessRole oder umgekehrt.

Zusätzlich (Systemebene, laut RBAC-Dokument): globale Rollen wie SysAdmin / SystemUser für mandantenübergreifende Sonderfälle; Mandantenrollen Admin / User / Viewer für Zugriff innerhalb eines Mandats.

Access Rules (DATA / UI / RESOURCE)

Kontexte

• DATA: Tabellen und Felder; CRUD über read, create, update, delete mit Access Levels a (all), m (my), g (group / Mandat), n (none); zusätzlich view.
• UI: Sichtbarkeit/Aktivierung von Oberflächenelementen; relevant ist view (boolean). Item-Format: kaskadierender String (z. B. playground.voice.settings).
• RESOURCE: Systemressourcen (KI-Modelle, Aktionen, …); ebenfalls primär view. Item-Format: kaskadierend (z. B. ai.model.anthropic).

Spezifität (pro Rolle)

Innerhalb einer Rolle gewinnt die spezifischste passende Regel (längster passender Präfix/exakter item) gegenüber generischen Regeln (item = null).

Mehrere Rollen

Über Rollen hinweg: Union — wenn eine Rolle nach interner Auflösung view: true liefert, gilt das Element als sichtbar/erlaubt (OR über Rollen). Für DATA werden die freizügigsten Stufen über Rollen kombiniert.

DATA: Öffnungsrechte (CUD vs. Read)

• Ohne Leserecht (read = n) keine CUD.
• Mit read = m sind CUD höchstens m oder n.
• Mit read = g sind CUD höchstens g, m oder n.
• Mit read = a sind alle Stufen für CUD zulässig.

Systemfelder (DATA)

Felder id und Namen mit führendem _ sind für Anwendungs-CUD geschützt; Connector erzwingt das unabhängig von Access Rules.

Frontend-Optionen für Rollen

frontend_options an Feldern kann statische Listen oder String-Referenzen (z. B. "user.role") nutzen; dynamische Optionen über /api/options/{optionsName}. Typ-Hilfen: gateway/modules/shared/frontendOptionsTypes.py.

Schlüssel-Dateien

Rolle	Pfad
RBAC-Auswertung / DB-Schicht	gateway/modules/interfaces/interfaceRbac.py
AccessRule- und Permission-Modelle	gateway/modules/datamodels/ (u. a. RBAC-bezogene Modelle)
Nutzer / Rollenlabels	User-Modell mit roleLabels (Multiselect, Union)
Konzept & Feldsemantik	wiki/appdoc/doc_security_role_based_access.md

Regeln / Invarianten

• Mandanten- vs. Feature-Rollen strikt trennen (keine Kreuz-Zuweisung der Label-Typen).
• Spezifisch vor generisch innerhalb einer Rolle; Union über Rollen.
• UI/RESOURCE: Effektiv sichtbar nur, wenn nach Regelauflösung view: true (kein hasAccess: false in Navigationskonzept — nicht berechtigte UI-Einträge werden gar nicht geliefert).
• DATA: Validierung der Regeln so, dass CUD nicht über dem jeweiligen Read-Level liegen.
• Performance-Ziel: DATA-Zugriffe mit RBAC-Filter in SQL, nicht erst vollständige Tabellen in Python filtern.