AA_PRINCIPAL_GROUP

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

Zweck

Gruppierung von Identitäten (AA_APP_USER, AA_SERVICE_ACCOUNT, andere AA_PRINCIPAL_GROUP). Rollen können einer Gruppe zugewiesen werden und werden transitiv an alle aktiven Mitglieder vererbt (siehe mdm.v_principal_role_active).

AA_PRINCIPAL_GROUP

Feld	Typ	Pflicht	Hinweise
id	uuid	ja	PK
key	text	ja	Format ^[a-z][a-z0-9_]*$, eindeutig
name	text	ja
description	text	nein
is_active	boolean	ja	default true
metadata	jsonb	ja	default '{}'
Audit-/Soft-Delete-Felder	–	–

AA_PRINCIPAL_GROUP_MEMBER

Feld	Typ	Pflicht	Hinweise
id	uuid	ja	PK
principal_group_id	uuid	ja	FK → AA_PRINCIPAL_GROUP
member_principal_type	mdm.principal_type	ja	nur user, AA_SERVICE_ACCOUNT, group
member_principal_id	uuid	ja	per Trigger gegen aktive Identität validiert
created_at, created_by	–	–
deleted_at, deleted_by	–	nein	Soft Delete

Indizes

• uq_principal_group_member_active UNIQUE partial auf Triple
• ix_principal_group_member_lookup für reverse Auflösung

Trigger

• trg_principal_group_member_validate_principal (siehe Trigger)

Hinweise

• Gruppen-in-Gruppen wird unterstützt; der Service muss Zyklen abfangen (Definition offen — Empfehlung: max. 8 Ebenen Tiefe, Detection via rekursivem CTE).
• IdP-Gruppen-Claims (Authentik) werden bei jedem Login synchronisiert — siehe Authentifizierung — Group-Sync. Unbekannte Gruppen werden als inaktiver Stub (is_active=false) angelegt und tauchen in mdm.v_principal_group_unassigned auf, bis ein Admin sie aktiviert und Rollen über AA_PRINCIPAL_ROLE zuweist.
• Membership-Pflege ist Authentik-driven: Mitgliedschaften, die nicht mehr im groups-Claim erscheinen, werden beim Login soft-gelöscht. Manuelle AA_PRINCIPAL_GROUP_MEMBER-Einträge ohne IdP-Quelle sind möglich (z. B. Service-Accounts), bleiben dann von der Sync-Logik unberührt — Unterscheidung über metadata.source.

Verwandte Dokumente

• Autorisierung
• AA_PRINCIPAL_ROLE