AA_ACL_ENTRY

Status: Entwurf · Quelle: Spec-Erweiterung RBAC/ACL · Spec-Kandidat: ja

Zweck

Feingranularer Allow/Deny-Override pro Principal + Scope. Ergänzt RBAC um zwei Fälle, die Rollen schlecht abdecken:

1. Datensatz-Ebene: „Benutzer X darf Datensatz Y bearbeiten, obwohl er sonst nur Leser ist.”
2. Attribut-Ebene: „Rolle Z darf das Attribut salary nicht sehen, auch wenn sie sonst Leser des Entitätstyps ist.”

Felder

Feld	Typ	Pflicht	Hinweise
id	uuid	ja	PK
principal_type	mdm.principal_type	ja
principal_id	uuid	ja	per Trigger validiert
action	mdm.permission_action	ja
effect	mdm.permission_effect	ja	default allow
scope	mdm.acl_scope	ja
scope_entity_type_id	uuid	nein	Pflicht wenn scope='entity_type'
scope_entity_id	uuid	nein	Pflicht wenn scope='entity'
scope_relation_type_id	uuid	nein	Pflicht wenn scope='relation_type'
attribute_key	text	nein	nur bei scope ∈ {DDM_ENTITY_TYPE, DDM_ENTITY}, Format ^[a-z][a-z0-9_]*$
valid_from / valid_to	timestamptz	nein	optionale Befristung
reason	text	nein	Begründung (für Audit-Recherche)
metadata	jsonb	ja	default '{}'
Audit-/Soft-Delete-Felder	–	–

Constraints und Trigger

• acl_entry_validity_chk, acl_entry_attribute_key_format_chk
• acl_entry_scope_consistency_chk: Scope-Felder + attribute_key-Restriktion
• trg_acl_entry_validate_principal: Existenz aktive Identität

Auflösungsregeln

• deny schlägt allow bei gleicher Spezifität.
• Spezifischerer Scope schlägt allgemeineren: DDM_ENTITY > DDM_ENTITY_TYPE > global. attribute_key zählt als zusätzliche Spezifität.
• Innerhalb gleicher Spezifität: ACL schlägt RBAC (ACL ist explizit, RBAC ist generisch).

Hinweise

• ACL wird nur für Ausnahmen genutzt — Regeln, die für alle Träger einer Rolle gelten, gehören in AA_ROLE_PERMISSION.
• Häufige Reads über ACL → Caching pro Request empfohlen.

Verwandte Dokumente

• Autorisierung
• Views