# 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.