RBAC-Mapping

Status: Entwurf

Wie werden die Fachrollen aus 50-roles/01-roles-and-permissions.md auf die System-Rollen und Permissions der Spec (docs/spec/70-security/02-authorization.md) abgebildet?

System-Rollen aus Spec

Die Spec definiert (is_system=true, immutable):

• administrator
• metadata_admin
• editor
• reader
• auditor
• exporter

Fachrolle → Spec-Rolle

Fachrolle	Spec-System-Rolle	+ Custom-Rolle	Begründung
Admin (Holding)	administrator	—	volle Konfiguration
Modellierer	metadata_admin	model_editor	metadata_admin für entity_type / entity_type_attribute / enum_set; eigene Rolle für model / model_version Schreiben
Stammdatenpfleger	editor	scope-eingeschränkt auf Stammdaten-Typen	editor mit role_permission.scope_entity_type_id ∈ Liste der Stammdatentypen
Analyst	editor	case_analyst	editor auf case, scenario, demand; reader auf Stammdaten
Management	reader	case_approver	reader Holding-weit, eigene Rolle für release-Action
Auditor	auditor	—	direkt aus Spec
Exporter	exporter	—	für Bulk-Export

Custom-Rollen (Seed)

model_editor

• read, create, update, archive auf model, model_version, model_test_case
• restore auf model_version
• KEINE release-Berechtigung — die liegt bei Management

case_analyst

• read Holding-weit auf alle Stammdaten-Entitätstypen (property, building, unit, provider, …)
• read, create, update, archive auf case, scenario, demand, assumption
• relate, unrelate für Bedarfs- und Szenario-Beziehungen

case_approver

• read Holding-weit
• spezielle Permission release auf case (entspricht Status-Übergang freigabe → aktiv)
• read_audit auf eigene approval-Aktionen (für Verteidigung im Prüfungs-Fall)

Permission-Aktionen

Spec-Set: read, create, update, archive, restore, soft_delete, hard_delete, relate, unrelate, export, manage_metadata, manage_permissions, read_audit

Workbench-spezifische Erweiterungen (custom permission-Einträge mit eigener Action):

Action	Bedeutung
release	Status-Übergang freigabe → aktiv auf case oder model_version
aggregate	Holding-Case-Aggregation auslösen
clone_scenario	Szenario klonen (eigene Action für Audit-Klarheit)

(Erweiterung der permission_action-Codeliste über enum_value — siehe Spec OP-37 für Codelisten-Versionierung.)

ACL-Beispiele

„Eigene Cases nur”

acl_entry:

• principal_type=role, principal_id=case_analyst
• scope=entity_type, scope_entity_type_id=case
• effect=allow, action=update
• • Trigger / Service-Layer-Constraint: nur wenn case.owner = $current_user

(Vereinfacht. Tatsächliche Implementierung evtl. über acl_entry pro Case-Anlage, Owner-getriggert. Detail offen.)

„Marge nicht für andere Töchter”

acl_entry:

• principal_type=group, principal_id=tochter_a_team
• scope=entity_type, scope_entity_type_id=case
• attribute_key=marge
• effect=deny, action=read

Greift bei Lesen der case.attributes.marge, blockiert das Feld nur für Tochter A — Tochter B sieht ihre Marge weiterhin.

„Holding-Aggregat nur Holding-Mgmt”

acl_entry:

• principal_type=role, principal_id=case_analyst (oder editor)
• scope=entity, scope_entity_id=$holding_case_id
• effect=deny, action=read
• Plus erlaubende Regel für principal=holding_management_group

Tenant-Scope

V1 läuft auf Default-Tenant public. Wenn V2 weitere Tenants aktiviert (mehrere Holdings auf einer Instanz):

• principal_role.scope_tenant_id setzen
• acl_entry mit scope=tenant, scope_tenant_id=$tenant

Wird über die Spec automatisch unterstützt (siehe docs/spec/30-domain-model/17-tenant.md).

OIDC-Mapping (Authentik)

Wenn Authentik (siehe projektmike/output/gettingtoyes/technik.md) als IdP eingesetzt wird:

• app_user.issuer_id = Authentik-Issuer-URL
• app_user.external_id = sub-Claim aus dem JWT
• roles-Claim (Authentik-Group) wird auf principal_group.key gemappt
• Service-Layer löst beim Login: User → principal_role-Einträge → effective permissions

Verwandte Dokumente

• ../50-roles/01-roles-and-permissions.md
• docs/spec/70-security/02-authorization.md
• docs/spec/30-domain-model/17-tenant.md
• projektmike/output/gettingtoyes/technik.md — Authentik-/OpenFGA-Setup im Original-Projekt (Hinweis: hier in Spec wird RBAC+ACL nativ in Postgres modelliert; OpenFGA ist eine Alternative, die im aktuellen Spec-Stand nicht vorgesehen ist)