internal/rbac/group.go: GroupStore verwaltet Gruppen innerhalb GENAU EINER
Tenant-Datenbank (Modell C, analog Store/TenantUserStore) — Tenant-Isolation
ist damit strukturell erfuellt, keine zusaetzliche Filterlogik noetig
(Akzeptanzkriterium 3). Nur 'user'/'tenant_admin' sind auf Gruppenebene
zuweisbar (dieselbe assignableRoles-Matrix wie bei direkter Zuweisung) —
superadmin bleibt mandantenuebergreifend und ausserhalb jeder Gruppenlogik.
EffectivePermissionsForUser vereinigt die direkte Rollenzuweisung (RBAC-01
Store) mit allen Rechten aus Gruppenrollen, live berechnet bei jedem Aufruf
statt zwischengespeichert — RemoveMember/DeleteGroup wirken dadurch sofort
(Akzeptanzkriterium 3). ON DELETE CASCADE auf group_members entzieht beim
Loeschen einer Gruppe die Mitgliedschaften automatisch, Benutzerkonten
selbst bleiben unberuehrt.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Gruppenrolle wirkt korrekt auf ALLE aktuellen Mitglieder —
TestGroup_RoleAffectsAllCurrentMembers: zwei Mitglieder, beide erhalten
die Gruppenrolle-Rechte. PASS.
2. Entfernen eines Benutzers aus der Gruppe entzieht Rechte sofort —
TestGroup_RemoveMemberRevokesRightsImmediately. PASS.
3. Gruppen sauber tenant-isoliert (Stichprobe ueber zwei Tenants) —
TestGroup_TenantIsolation: Gruppe in Tenant A taucht in Tenant B nicht
auf. PASS.
Zusaetzlich: TestGroup_DeleteGroupRevokesRightsWithoutDeletingUser belegt
Akzeptanzkriterium 3 (Loeschung ohne Benutzerkonto-Verlust) konkret. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
internal/rbac: drei Grundrollen (superadmin, tenant_admin, user) mit
Hierarchie ueber eine einfache Eltern-Map (tenant_admin erbt von user,
superadmin erbt von tenant_admin) — EffectivePermissions loest die volle
vererbte Rechtemenge auf (Akzeptanzkriterium 2). Policy-Modell bewusst als
reine Go-Datenstruktur getrennt von der Durchsetzung (RBAC-02), nach
Casbin-Prinzip.
Store verwaltet Rollenzuweisungen innerhalb EINER Tenant-Datenbank (Modell C,
analog internal/user.TenantUserStore) — nur 'user' und 'tenant_admin' sind
hier zuweisbar (assignableRoles-Matrix). Ein Zuweisungsversuch fuer
'superadmin' wird abgewiesen, da diese Rolle mandantenuebergreifend ist und
bereits durch die Existenz eines Kontos in IAM-01s SuperadminStore
repraesentiert wird — keine doppelte Modellierung. Jede Zuweisung schreibt
zusaetzlich einen Historieneintrag (role_assignment_history) mit
grantedBy/grantedAt, atomar in derselben Transaktion (Akzeptanzkriterium 3).
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Zuweisung ausserhalb der erlaubten Matrix abgewiesen —
TestStore_RejectsSuperadminOutsideAllowedMatrix und
TestStore_RejectsUnknownRole: beide ErrRoleNotAssignableInTenantScope,
kein Datensatz hinterlassen. PASS.
2. Rollenhierarchie liefert erwartete effektive Rechtemenge —
TestEffectivePermissions_Inheritance: tenant_admin hat geerbte
user-Rechte + eigene, aber nicht platform.manage_tenants; superadmin hat
die volle Kette. PASS.
3. Datenmodell von zweiter Person gegen Dokumentation geprueft — NICHT
durchgefuehrt (keine zweite Person in dieser Session verfuegbar). Offen.
Zusaetzlich automatisiert getestet (Akzeptanzkriterium 3):
TestStore_HistoryTracksWhoAndWhen — zwei aufeinanderfolgende Zuweisungen,
Historie liefert beide mit korrektem grantedBy in chronologischer
Reihenfolge. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Benutzer-Datenmodell + CRUD fuer Tenant-User (tenant-scoped, keine
tenant_id-Spalte noetig, Tenant ergibt sich aus der DB-Verbindung, Modell C)
und getrennt dafuer SuperadminStore fuer mandantenuebergreifende Konten in
der Registry-DB — First-Class-Typ statt tenant_id-NULL-Sonderfall im
Tenant-User-Code (bekannter archivdms-Fehler vermieden).
E-Mail-Eindeutigkeit: tenant-scoped fuer normale Benutzer (UNIQUE-Constraint
gilt nur innerhalb der jeweiligen Tenant-DB), global fuer Superadmins
(eine Registry-DB, ein UNIQUE-Constraint).
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. CRUD automatisiert getestet inkl. Negativfaellen — TestTenantUserStore_CRUD
deckt doppelte E-Mail (ErrEmailTaken) und unbekannte ID ab. PASS.
2. Superadmin-Anlage ohne Tenant-Kontext — TestSuperadminStore_CreateWithoutTenantContext:
SuperadminStore.Create hat syntaktisch keinen Tenant-Parameter, kein
if-Zweig fuer "kein Tenant" im Code. PASS.
3. Datenmodell von zweiter Person gegen Dokumentation geprueft — NICHT
durchgefuehrt (keine zweite Person in dieser Session verfuegbar). Offen.
Tenant-User-Handler ist im Code vorhanden, aber in cmd/core/main.go noch
nicht geroutet — braucht Connection-Routing pro Mandant (TEN-06), das nicht
Teil dieser Kachel ist. Nur der Superadmin-Endpunkt ist verdrahtet.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Registry-DB (nur Tenant-Metadaten), Provisioning-Routine legt pro Mandant
eine physisch isolierte Postgres-DB an und registriert sie transaktional
(Rollback der DB bei fehlgeschlagener Registrierung). Schlanker HTTP-Handler
als Schnittstellen-Vorbereitung fuer API-01/TEN-02, kein eigenes REST-Grundgerüst.
Pruefungen:
1. Migration up/down geschrieben (0001_tenant_registry.{up,down}.sql) — nicht
gegen echte DB ausgefuehrt, da auf dieser Maschine kein Go/Postgres-Test-
Setup verfuegbar ist. Offen zur Ausfuehrung.
2. Integrationstest TestProvision_CreatesIsolatedDatabases geschrieben (zwei
Mandanten, prueft unterschiedliche db_name und current_database()) —
ebenfalls nicht ausgefuehrt, guarded per TEST_ADMIN_DSN env var. Offen.
3. Slug-Validierung (unit test TestValidateSlug) deckt SQL-Injection-Versuch
im Datenbanknamen ab — ebenfalls nicht lokal ausgefuehrt, da kein Go
Compiler auf dieser Maschine vorhanden ist. Offen.
Alle drei Pruefungen sind vorbereitet, aber NICHT durchgefuehrt worden —
zaehlen laut Vorgabe als offen bis auf einer Maschine mit Go+Postgres verifiziert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
