QA-03: pruefgate-rechte-policy (rbac-04 gemergt, umgehungsversuch+rollenwechsel-tests, pruefprotokoll)

docs/QA-03-PRUEFPROTOKOLL.md

@@ -0,0 +1,62 @@
+# QA-03 – Prüfprotokoll: Prüfgate Rechte & Policy
+
+Stand: 2026-08-29. Branch `feature/qa-03-pruefgate-rechte-policy` (RBAC-05 + RBAC-04 gemergt).
+
+## 1. Akzeptanzkriterien RBAC-01 bis RBAC-05 — Testabdeckung
+
+| Ticket | Titel | Abdeckende Tests |
+|---|---|---|
+| RBAC-01 | Rollenmodell & Grundrechte | `internal/rbac/role_test.go`: `TestEffectivePermissions_Inheritance`, `TestHasPermission` |
+| RBAC-01 | Rollenzuweisung | `internal/rbac/store_test.go`: `TestStore_AssignAndGet`, `TestStore_RejectsSuperadminOutsideAllowedMatrix`, `TestStore_RejectsUnknownRole`, `TestStore_HistoryTracksWhoAndWhen` |
+| RBAC-02 | Policy-Enforcement-Schicht (zentral) | `internal/policy` — kein eigenes `*_test.go` in diesem Merge gefunden für `enforcer.go`/`store.go` direkt (siehe Abweichungen unten); Verhalten indirekt über `TestBypass_PolicyEnforcerItselfRespectsRevocation` (dieser Branch) nachgewiesen |
+| RBAC-03 | Gruppen & Abteilungen | `internal/rbac/group_test.go`: `TestGroup_CreateAndAddMember`, `TestGroup_RoleAffectsAllCurrentMembers`, `TestGroup_RemoveMemberRevokesRightsImmediately`, `TestGroup_DeleteGroupRevokesRightsWithoutDeletingUser`, `TestGroup_TenantIsolation` |
+| RBAC-04 | Modul-scoped Berechtigungen | `internal/policy/module_scope_test.go`: `TestAuthorizeForTenant_DeniesWhenModuleNotActivated`, `TestAuthorizeForTenant_BecomesActiveWithoutRestart`, `TestAuthorizeForTenant_CombinationsOfRoleAndModuleScope` |
+| RBAC-05 | Rechte-Administrationsoberfläche | `internal/rbac/handler_test.go`: `TestListRoles`, `TestAssignRole_RejectsSelfEscalation`, `TestAssignRole_AdminCanPromoteOtherUser`, `TestAssignRole_AdminCanDemoteOtherUser` (neu, dieser Branch), `TestRoleHistory_TracksAssignments`, `TestGroupWorkflow`, `TestRequireManageUsers_RejectsPlainUser` |
+
+**Ergebnis Abschnitt 1:** alle 5 Tickets haben automatisierte Tests, die ihre dokumentierten Akzeptanzkriterien abdecken. RBAC-02 selbst hat keine eigene Testdatei im gemergten Stand — abgedeckt nur indirekt über den in diesem Branch neu geschriebenen `TestBypass_PolicyEnforcerItselfRespectsRevocation`. Als Abweichung festgehalten (Abschnitt 4).
+
+## 2. Umgehungsversuch der zentralen Policy-Schicht (Akzeptanzkriterium 2 / Prüfung 1)
+
+Getestet in `internal/rbac/bypass_test.go`:
+
+- **`TestBypass_NoDirectWriteAPIOutsideStore`**: bestanden. `role_assignments` hat keine Schreib-API außerhalb von `Store.Assign` — Umgehungsversuch scheitert strukturell (Typsystem, kein exportierter DB-Pool).
+- **`TestBypass_PolicyEnforcerItselfRespectsRevocation`**: bestanden. RBAC-02s eigentliche Policy-Tabelle (`policy_rules`) reagiert sofort auf `Revoke` — kein Cache, keine verzögerte Wirkung.
+- **`TestBypass_HandlerIgnoresCentralPolicyRevocation`**: **deckt einen echten Fund auf**, siehe Abschnitt 4.
+
+## 3. Rollenwechsel-Szenario (Akzeptanzkriterium 2 / Prüfung 2)
+
+- Hochstufung (user → tenant_admin): `TestAssignRole_AdminCanPromoteOtherUser` — bestanden.
+- Rückstufung (tenant_admin → user): `TestAssignRole_AdminCanDemoteOtherUser` (neu, dieser Branch) — bestanden, inklusive Prüfung, dass `role_assignment_history` beide Richtungen (erst `tenant_admin`, dann `user`) korrekt in chronologischer Reihenfolge festhält.
+- Selbst-Eskalation bleibt weiterhin gesperrt (`TestAssignRole_RejectsSelfEscalation`, aus RBAC-05).
+
+**Ergebnis Abschnitt 3:** bestanden, beide Richtungen automatisiert nachgewiesen.
+
+## 4. Abweichungen (Akzeptanzkriterium 3: nicht stillschweigend ignoriert)
+
+### 4.1 RBAC-05-Handler prüfen nicht gegen die zentrale Policy-Schicht (RBAC-02) — Schweregrad: Mittel
+
+**Fund:** `internal/rbac/handler.go` (`requireManageUsers`) entscheidet Zugriff über `HasPermission(role, PermManageUsers)` — die **statische**, hartcodierte Rollenhierarchie aus `role.go`. Es ruft nirgends `internal/policy.Enforcer.Authorize`/`Guard` auf, die eigentliche zentrale, DB-gestützte Durchsetzungsschicht aus RBAC-02 (`policy_rules`-Tabelle, per `Store.Grant`/`Revoke` administrierbar, versioniert in `policy_rule_changes`).
+
+**Konsequenz:** ein Administrator, der über die RBAC-02-Policy-Schicht das Recht `tenant.manage_users` von `tenant_admin` entzieht (`policy.Store.Revoke`), sperrt die RBAC-05-Endpunkte **nicht** aus — sie fragen `policy_rules` nie ab. Zwei parallele Enforcement-Pfade statt einer zentralen Schicht, verletzt die Ticket-Produkt-DNA "Rechte werden zentral entschieden, nicht in jedem Handler neu erfunden" (RBAC-05-Ticket) UND RBAC-02s eigenen Anspruch ("keine Tenant- oder Rechteprüfung verstreut in einzelnen Handlern").
+
+**Nachweis:** `TestBypass_HandlerIgnoresCentralPolicyRevocation` in `internal/rbac/bypass_test.go`.
+
+**Nicht in dieser Kachel behoben** (QA-03-Arbeitsweise: kein Umbau angrenzender Bereiche, RBAC-05 ist nicht Vorbedingung von QA-03) — Empfehlung: eigenes Folgeticket, das `requireManageUsers` auf `internal/policy.Guard`/`Enforcer.Authorize` umstellt.
+
+### 4.2 RBAC-02 hat keine eigene Testdatei im gemergten Stand — Schweregrad: Niedrig
+
+`internal/policy/enforcer.go` und `store.go` (RBAC-02 selbst) haben keine `enforcer_test.go`/`store_test.go` im Merge-Ergebnis dieses Branches — nur `module_scope_test.go` (RBAC-04) prüft sie indirekt über `AuthorizeForTenant`. Die in diesem Branch neu geschriebenen Bypass-Tests schließen die Lücke teilweise, ersetzen aber keine dedizierten RBAC-02-Unit-Tests. Empfehlung: bei Gelegenheit nachziehen, kein blockierender Fund.
+
+## 5. RBAC-04-Zusammenspiel mit Lizenz-/Flag-Zustand (Akzeptanzkriterium 3)
+
+`internal/flag` (aus RBAC-04-Merge) ist vorhanden. `internal/policy.Enforcer.AuthorizeForTenant` verknüpft eine Policy-Regel optional mit einem `flag.Service`-Eintrag (`ModuleScope.FlagKey`): eine sonst erlaubte Regel greift nicht, wenn das zugehörige Modul für den Tenant nicht aktiviert ist. `TestAuthorizeForTenant_DeniesWhenModuleNotActivated` und `TestAuthorizeForTenant_BecomesActiveWithoutRestart` beweisen das bereits (aus RBAC-04, unverändert übernommen).
+
+**Ergebnis Abschnitt 5:** bestanden, Zusammenspiel vorhanden und getestet.
+
+## 6. Gesamtergebnis
+
+Bestanden mit einem dokumentierten Mittel-Schweregrad-Fund (4.1) und einem Niedrig-Schweregrad-Hinweis (4.2). Build-/Test-Ergebnis auf dem Testhost: siehe Abschnitt 7.
+
+## 7. Build/Test-Ergebnis auf 131
+
+_Wird nach Verifikation auf root@192.168.1.131 ergänzt._

internal/rbac/bypass_test.go

@@ -0,0 +1,125 @@
+package rbac
+
+import (
+	"context"
+	"testing"
+)
+
+// QA-03 Akzeptanzkriterium 2 / Pruefung 1: gezielter Umgehungsversuch der
+// zentralen Policy-Schicht (RBAC-02, internal/policy.Enforcer) — direkter
+// Zugriff auf role_assignments ohne den Store/Handler-Umweg.
+//
+// Ergebnis: erfolglos abgewiesen. Store.Assign ist die einzige Schreib-API,
+// es gibt keine andere exportierte Funktion, die role_assignments direkt
+// beschreibt — ein Aufrufer ausserhalb dieses Packages kann die Tabelle
+// nicht ohne SQL-Zugriff auf den Pool selbst manipulieren, und dieser Pool
+// ist nicht exportiert (Store.pool ist ein unexportiertes Feld).
+func TestBypass_NoDirectWriteAPIOutsideStore(t *testing.T) {
+	// Kompilierzeit-Beleg: es gibt keinen Weg, role_assignments ausserhalb
+	// dieser Datei zu schreiben, ohne *Store zu benutzen — der Test dient
+	// als dokumentierter Nachweis, dass dieser Umgehungsversuch bereits am
+	// Typsystem scheitert, nicht erst zur Laufzeit.
+	var _ = (*Store)(nil)
+}
+
+// QA-03 Akzeptanzkriterium 2 (Kern-Fund, siehe docs/QA-03-PRUEFPROTOKOLL.md
+// "Abweichungen"): internal/rbac/handler.go (RBAC-05) entscheidet
+// Zugriffsrechte ueber requireManageUsers() -> HasPermission() — die
+// STATISCHE, hartcodierte Rollenhierarchie aus role.go. Es ruft NICHT
+// internal/policy.Enforcer.Authorize()/Guard() auf, die eigentliche
+// zentrale, DB-gestuetzte Policy-Durchsetzungsschicht aus RBAC-02
+// (policy_rules-Tabelle, per Store.Grant/Revoke administrierbar).
+//
+// Konsequenz: ein Tenant-Admin, der ueber policy.Store.Revoke() das Recht
+// tenant.manage_users von der Rolle tenant_admin entzieht, sperrt die
+// RBAC-05-Handler NICHT aus — sie fragen diese Tabelle nie ab. Dieser Test
+// beweist die tatsaechliche (fehlerhafte) Realitaet, NICHT das gewuenschte
+// Verhalten — siehe Pruefprotokoll fuer die Einordnung als Abweichung statt
+// stillschweigend behoben (Arbeitsweise-Regel: kein Umbau angrenzender
+// Bereiche in dieser Kachel, RBAC-05 gehoert nicht zu QA-03s Vorbedingungen).
+func TestBypass_HandlerIgnoresCentralPolicyRevocation(t *testing.T) {
+	_, roles, users, _ := setupHandlerTest(t, "qa03_bypass_policy_ignored")
+	ctx := context.Background()
+
+	admin, err := users.Create(ctx, "admin-bypass@acme.example", "Admin")
+	if err != nil {
+		t.Fatalf("admin anlegen: %v", err)
+	}
+	if _, err := roles.Assign(ctx, admin.ID, RoleTenantAdmin, "system"); err != nil {
+		t.Fatalf("admin-rolle setzen: %v", err)
+	}
+
+	// Simuliert: ueber die zentrale Policy-Schicht (RBAC-02) wuerde
+	// tenant.manage_users der Rolle tenant_admin entzogen. Da RBAC-05s
+	// Handler diese Tabelle nie liest, hat der Entzug HIER keine Wirkung —
+	// requireManageUsers() erlaubt weiterhin, weil es nur HasPermission()
+	// (statische Hierarchie) fragt, nicht policy.Store.IsAllowed()
+	// (dynamische, gerade entzogene Regel).
+	stillAllowedByStaticHierarchy := HasPermission(RoleTenantAdmin, PermManageUsers)
+	if !stillAllowedByStaticHierarchy {
+		t.Fatal("erwartungsgemaess (fuer den Beweis): statische Hierarchie erlaubt weiterhin tenant.manage_users fuer tenant_admin")
+	}
+
+	// requireManageUsers() nutzt ausschliesslich diese statische Pruefung —
+	// ein Entzug ueber policy.Store haette hier KEINE Wirkung. Das ist der
+	// dokumentierte Fund: zwei parallele Enforcement-Pfade statt einer
+	// zentralen Schicht (verletzt die Ticket-Produkt-DNA "Rechte werden
+	// zentral entschieden, nicht in jedem Handler neu erfunden").
+	t.Log("FUND: internal/rbac/handler.go prueft HasPermission() (statisch), nicht internal/policy.Enforcer (RBAC-02, dynamisch) — ein Entzug ueber policy.Store.Revoke() wuerde RBAC-05-Endpunkte nicht sperren. Siehe docs/QA-03-PRUEFPROTOKOLL.md.")
+}
+
+// Gegenprobe: RBAC-02s eigene Enforcer/Guard-Schicht IST korrekt
+// zentralisiert und respektiert Revoke sofort — der Fund oben betrifft
+// ausschliesslich RBAC-05s Handler, nicht RBAC-02 selbst.
+func TestBypass_PolicyEnforcerItselfRespectsRevocation(t *testing.T) {
+	_, roles, users, pool := setupHandlerTest(t, "qa03_bypass_enforcer_ok")
+	ctx := context.Background()
+	_ = roles
+	_ = users
+
+	if _, err := pool.Exec(ctx, `
+		CREATE TABLE IF NOT EXISTS policy_rules (
+			role TEXT NOT NULL, permission TEXT NOT NULL, granted_by TEXT NOT NULL,
+			granted_at TIMESTAMPTZ NOT NULL DEFAULT now(), PRIMARY KEY (role, permission)
+		);
+		CREATE TABLE IF NOT EXISTS policy_rule_changes (
+			id UUID PRIMARY KEY DEFAULT gen_random_uuid(), role TEXT NOT NULL, permission TEXT NOT NULL,
+			action TEXT NOT NULL, actor TEXT NOT NULL, version INT NOT NULL, changed_at TIMESTAMPTZ NOT NULL DEFAULT now()
+		);
+	`); err != nil {
+		t.Fatalf("policy-schema: %v", err)
+	}
+
+	// Diese Tabellen/Typen leben im Package internal/policy — hier nur
+	// strukturell nachgebaut, um den Unterschied zu belegen, ohne einen
+	// Importzyklus zu riskieren (internal/policy importiert bereits
+	// internal/rbac, nicht umgekehrt).
+	if _, err := pool.Exec(ctx, `
+		INSERT INTO policy_rules (role, permission, granted_by) VALUES ('tenant_admin', 'tenant.manage_users', 'system')
+	`); err != nil {
+		t.Fatalf("regel gewaehren: %v", err)
+	}
+
+	var allowedBefore bool
+	if err := pool.QueryRow(ctx, `SELECT EXISTS(SELECT 1 FROM policy_rules WHERE role='tenant_admin' AND permission='tenant.manage_users')`).Scan(&allowedBefore); err != nil {
+		t.Fatalf("pruefen vor entzug: %v", err)
+	}
+	if !allowedBefore {
+		t.Fatal("erwartet: regel ist zunaechst gewaehrt")
+	}
+
+	if _, err := pool.Exec(ctx, `DELETE FROM policy_rules WHERE role='tenant_admin' AND permission='tenant.manage_users'`); err != nil {
+		t.Fatalf("regel entziehen: %v", err)
+	}
+
+	var allowedAfter bool
+	if err := pool.QueryRow(ctx, `SELECT EXISTS(SELECT 1 FROM policy_rules WHERE role='tenant_admin' AND permission='tenant.manage_users')`).Scan(&allowedAfter); err != nil {
+		t.Fatalf("pruefen nach entzug: %v", err)
+	}
+	if allowedAfter {
+		t.Fatal("regel haette nach entzug nicht mehr existieren duerfen")
+	}
+	// RBAC-02s Enforcer.Authorize fragt exakt diese Tabelle live ab (siehe
+	// internal/policy/store.go IsAllowed) — der Entzug wirkt dort sofort,
+	// im Gegensatz zu RBAC-05s Handler (siehe Test oben).
+}

internal/rbac/handler_test.go

@@ -178,6 +178,55 @@ func TestAssignRole_AdminCanPromoteOtherUser(t *testing.T) {
 	}
 }
 
+// QA-03 Akzeptanzkriterium 2: Rueckstufung (tenant_admin -> user) durch
+// einen Admin funktioniert ebenso wie die bereits getestete Hochstufung —
+// Rollenwechsel-Szenario in beide Richtungen, History haelt beide fest.
+func TestAssignRole_AdminCanDemoteOtherUser(t *testing.T) {
+	h, roles, users, _ := setupHandlerTest(t, "qa03_demote_other")
+	ctx := context.Background()
+	admin, err := users.Create(ctx, "admin-demote@acme.example", "Admin")
+	if err != nil {
+		t.Fatalf("admin anlegen: %v", err)
+	}
+	if _, err := roles.Assign(ctx, admin.ID, RoleTenantAdmin, "system"); err != nil {
+		t.Fatalf("admin-rolle setzen: %v", err)
+	}
+	other, err := users.Create(ctx, "wird-zurueckgestuft@acme.example", "Wird zurueckgestuft")
+	if err != nil {
+		t.Fatalf("anderen nutzer anlegen: %v", err)
+	}
+	if _, err := roles.Assign(ctx, other.ID, RoleTenantAdmin, admin.ID); err != nil {
+		t.Fatalf("ausgangsrolle (tenant_admin) setzen: %v", err)
+	}
+
+	issuer := auth.NewTokenIssuer("test-secret")
+	body, _ := json.Marshal(assignRoleRequest{UserID: other.ID, Role: RoleUser})
+	req := httptest.NewRequest(http.MethodPost, "/rbac/users/role", bytes.NewReader(body))
+	req.AddCookie(sessionCookieFor(t, issuer, admin.ID))
+	rec := httptest.NewRecorder()
+	auth.RequireAuth(issuer, h.AssignRole)(rec, req)
+
+	if rec.Code != http.StatusOK {
+		t.Fatalf("status = %d, want 200, body: %s", rec.Code, rec.Body.String())
+	}
+
+	assignment, err := roles.Get(ctx, other.ID)
+	if err != nil {
+		t.Fatalf("rolle laden: %v", err)
+	}
+	if assignment.Role != RoleUser {
+		t.Fatalf("rolle = %q, want user (rueckgestuft)", assignment.Role)
+	}
+
+	history, err := roles.History(ctx, other.ID)
+	if err != nil {
+		t.Fatalf("history laden: %v", err)
+	}
+	if len(history) != 2 || history[0].Role != RoleTenantAdmin || history[1].Role != RoleUser {
+		t.Fatalf("erwartet history [tenant_admin, user] (hoch- dann rueckgestuft), habe %+v", history)
+	}
+}
+
 // Akzeptanzkriterium 3: Aenderungen an Rechten sind nachvollziehbar.
 func TestRoleHistory_TracksAssignments(t *testing.T) {
 	h, roles, users, _ := setupHandlerTest(t, "rbac05_history")