Files
nexarch/docs/RBAC-07-PRUEFPROTOKOLL.md
T
sysops bc46c3e320 RBAC-07: rechte-administrations-dienst-starten
- cmd/rbac-admin-api: startet internal/rbac.Handler (RBAC-05), hinter
  auth.RequireAuth mit demselben JWT-Secret wie IAM-16 (account-api)
- reines Wiring, kein Diff an internal/rbac/ (verifiziert)
- real deployed auf 131, cross-service-Session real bewiesen: Login
  gegen account-api (Port 8099), dasselbe Session-Cookie gegen
  rbac-admin-api (Port 8100) verwendet -> echte Rollenliste, ohne
  Cookie -> 401
- Migrationen (role_assignments/groups) real auf tenant_acme
  angewendet, reale Grant-Luecke behoben und verifiziert
- Bootstrap-Erkenntnis dokumentiert: ListRoles selbst verlangt bereits
  eine Rolle mit PermManageUsers, Testnutzer daher mit direkter
  DB-Bootstrap-Rolle angelegt (wie Ersteinrichtung)

Pruefungen siehe docs/RBAC-07-PRUEFPROTOKOLL.md
2026-08-30 21:24:35 +02:00

3.5 KiB
Raw Blame History

RBAC-07 Prüfprotokoll: Rechte-Administrations-Dienst starten (RBAC-05 als laufender Dienst)

Voraussetzung RBAC-05, IAM-16 beide bereits Fertig, hier UNVERÄNDERT.

Reines Wiring, keine neue Logik

git diff --stat internal/rbac/ liefert KEINEN Diff. cmd/rbac-admin-api/main.go setzt ausschließlich bestehende Konstruktoren zusammen und wrappt jeden Endpunkt mit auth.RequireAuth — derselben Middleware, die IAM-16 bereits nutzt.

JWT-Secret-Konsistenz (explizit geprüft, nicht nur konfiguriert)

NEXARCH_RBACADMIN_JWT_SECRET MUSS identisch mit NEXARCH_ACCOUNT_JWT_SECRET (IAM-16) sein, sonst verwirft dieser Dienst gültige account-api-Sessions. Real getestet: mit account-api (Port 8099) eingeloggt, Session-Cookie unverändert gegen rbac-admin-api (Port 8100, ANDERER Prozess, ANDERE Portnummer) verwendet — Cookie wurde real akzeptiert, kein zweiter Login nötig. Das beweist die Cross-Service- Gültigkeit, nicht nur eine übereinstimmende Konfigurationszeile.

Bootstrap-Erkenntnis (dokumentiert)

internal/rbac.Handler.ListRoles verlangt selbst bereits eine Rolle mit PermManageUsers (requireManageUsers) — ein Benutzer OHNE role_assignments-Zeile bekommt 403, auch für die reine Rollenliste. Für den End-zu-Ende-Test wurde daher ein Testnutzer mit einer direkt in der DB gesetzten tenant_admin-Bootstrap-Zeile angelegt (wie eine Ersteinrichtung) — kein Umgehen der echten Prüfung, sondern deren Voraussetzung.

Umsetzung

  • cmd/rbac-admin-api/main.go Rollen/Gruppen-Endpunkte (GET /rbac/roles, POST /rbac/users/role, GET /rbac/users/{id}/history, GET/POST /rbac/groups*), alle hinter auth.RequireAuth.
  • deploy/systemd/nexarch-rbac-admin-api.service.tmpl.

Prüfungen

# Prüfung Ergebnis
1 Dienst startet und bleibt stabil (systemctl status aktiv) bestanden real auf 131: nexarch-rbac-admin-api.service aktiv
2 Realer Aufruf mit gültigem IAM-16-Session-Cookie liefert die erwartete Rollenliste, ohne/mit falschem Cookie 401/403 bestanden real per curl: mit dem bei account-api (IAM-16) ausgestellten Cookie → 200 mit der echten Rollen-/Rechte-Liste (tenant_admin, user); ohne Cookie → 401
3 Code-Review: keine Änderung an internal/rbac/ selbst, nur main.go+systemd neu bestanden git diff --stat internal/rbac/ liefert leeren Diff

Echte Verdrahtung auf 192.168.1.131

  • rbac-admin-api gebaut nach /opt/nexarch-core/bin/, /etc/nexarch/rbac-admin-api.env (0600, NEXARCH_RBACADMIN_JWT_SECRET identisch zu NEXARCH_ACCOUNT_JWT_SECRET), Dienst installiert/aktiviert.
  • Migrationen 0002_role_assignments, 0003_groups real auf tenant_acme angewendet (fehlten dort), reale Grant-Lücke gefunden und behoben (role_assignments, role_assignment_history, groups, group_members), über information_schema.role_table_grants verifiziert.
  • End-zu-Ende-Beweis: Testnutzer mit Bootstrap-tenant_admin-Rolle, Login gegen account-api, dasselbe Cookie gegen rbac-admin-api verwendet → echte Rollenliste. Testdaten anschließend entfernt.

Build/Test-Ergebnis (192.168.1.131)

go build ./...  -> clean
go vet ./...    -> clean
golangci-lint run ./cmd/rbac-admin-api/...  -> 0 issues

Gesamtergebnis

Bestanden. RBAC-05 ist jetzt ein real laufender, über systemd verwalteter Dienst, cross-service authentifiziert über dieselbe IAM-16-Session — der zweite Baustein der browserfähigen Core-GUI nach TEN-05.