sysops
bc46c3e320
- 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
76 lines
3.5 KiB
Markdown
76 lines
3.5 KiB
Markdown
# 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.
|