- 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
3.5 KiB
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 hinterauth.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-apigebaut nach/opt/nexarch-core/bin/,/etc/nexarch/rbac-admin-api.env(0600,NEXARCH_RBACADMIN_JWT_SECRETidentisch zuNEXARCH_ACCOUNT_JWT_SECRET), Dienst installiert/aktiviert.- Migrationen
0002_role_assignments,0003_groupsreal auftenant_acmeangewendet (fehlten dort), reale Grant-Lücke gefunden und behoben (role_assignments,role_assignment_history,groups,group_members), überinformation_schema.role_table_grantsverifiziert. - End-zu-Ende-Beweis: Testnutzer mit Bootstrap-
tenant_admin-Rolle, Login gegenaccount-api, dasselbe Cookie gegenrbac-admin-apiverwendet → 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.