69 lines
4 KiB
Markdown
69 lines
4 KiB
Markdown
<!-- status: canonical -->
|
|
<!-- lastReviewed: 2026-04-05 -->
|
|
<!-- verifiedAgainst: gateway (codebase audit 2026-03-29) -->
|
|
|
|
# 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.
|