# 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.