sysops
3b3991f54f
- cmd/account-api: tenant-gescopter Login/Account-Dienst, setzt die fertigen IAM-08-Handler zusammen (auth, authtoken, totp) - Login ueber totp.Handler.Login (deckt 2FA optional mit ab), Passwort-Reset ueber authtoken.LogNotifier (IAM-08s eigene Uebergangsloesung) - reines Wiring, kein Diff an internal/auth|authtoken|totp|user (verifiziert) - real deployed auf 131, end-zu-ende per curl: falsches Passwort->401, korrektes Passwort->echte Session-Cookie, geschuetzter Endpunkt mit Cookie->200 (echte Nutzerdaten), ohne Cookie->401 - Migrationen (users/totp/password_tokens) real auf tenant_acme angewendet, reale Grant-Luecke behoben und verifiziert - RBAC-05s Board-dependsOn um IAM-16 ergaenzt (RBAC-05 braucht dieselbe Auth-Middleware, bei Sichtpruefung festgestellt) Pruefungen siehe docs/IAM-16-PRUEFPROTOKOLL.md
79 lines
4.0 KiB
Markdown
79 lines
4.0 KiB
Markdown
# IAM-16 – Prüfprotokoll: Login/Account-Dienst starten (IAM-08 als laufender Dienst)
|
||
|
||
Voraussetzung IAM-08 – bereits Fertig, hier UNVERÄNDERT.
|
||
|
||
## Bedeutung über IAM-08 hinaus
|
||
|
||
IAM-16 ist nicht nur die Voraussetzung für die IAM-08-eigenen Prüfungen,
|
||
sondern die grundlegende Session-/Auth-Infrastruktur für JEDE
|
||
Auth-geschützte Core-GUI (`auth.RequireAuth`/`auth.ClaimsFromContext`).
|
||
Bei der RBAC-05-Sichtprüfung wurde festgestellt, dass
|
||
`internal/rbac.Handler.ListRoles` genau diese Middleware voraussetzt —
|
||
RBAC-05s Board-`dependsOn` wurde entsprechend um IAM-16 ergänzt.
|
||
|
||
## Reines Wiring, keine neue Logik
|
||
|
||
`git diff --stat internal/auth/ internal/authtoken/ internal/totp/ internal/user/`
|
||
liefert KEINEN Diff gegenüber dem IAM-08-Stand. `cmd/account-api/main.go`
|
||
setzt ausschließlich bestehende Konstruktoren zusammen (u. a.
|
||
`totp.Handler.Login` als DER EINE Login-Endpunkt, der optional 2FA
|
||
mitprüft — bereits so von IAM-08 dokumentiert). Passwort-Reset nutzt
|
||
`authtoken.LogNotifier{}` — ebenfalls bereits von IAM-08 als
|
||
Übergangslösung bereitgestellt (Versand über CFG-02/CFG-05 ist explizit
|
||
ein späterer Austausch, kein IAM-16-Thema).
|
||
|
||
## Umsetzung
|
||
|
||
- `cmd/account-api/main.go` – tenant-gescopter (Modell C) Login/Account-
|
||
Dienst: `POST /auth/login` (2FA-fähig), `POST /auth/logout`,
|
||
`POST /auth/password-reset/{request,complete}`, `GET /account/me`,
|
||
`POST /account/change-password`, `GET/POST /auth/totp/*` (Status/
|
||
Setup) — letztere drei hinter `auth.RequireAuth`.
|
||
- `deploy/systemd/nexarch-account-api.service.tmpl`.
|
||
|
||
## Prüfungen
|
||
|
||
| # | Prüfung | Ergebnis |
|
||
|---|---|---|
|
||
| 1 | Dienst startet und bleibt stabil (systemctl status aktiv) | **bestanden** – real auf 131: `nexarch-account-api.service` aktiv, `Restart=on-failure` |
|
||
| 2 | Realer Login-Versuch (korrektes Passwort) liefert eine gültige Session, falsches Passwort wird abgelehnt | **bestanden** – real per `curl`: falsches Passwort → 401 (`invalid_credentials`); korrektes Passwort → 200 mit echtem, signiertem `nexarch_session`-JWT-Cookie (`HttpOnly`, `Secure`, `SameSite=Strict`); anschließend `GET /account/me` MIT Cookie → 200 mit den echten Nutzerdaten, OHNE Cookie → 401 |
|
||
| 3 | Code-Review: keine Änderung an internal/auth/, internal/authtoken/, internal/totp/ selbst, nur main.go+systemd neu | **bestanden** – `git diff --stat` bestätigt: alle vier Pakete unverändert gegenüber IAM-08 |
|
||
|
||
## Echte Verdrahtung auf 192.168.1.131
|
||
|
||
- `account-api` gebaut nach `/opt/nexarch-core/bin/`,
|
||
`/etc/nexarch/account-api.env` (0600), `nexarch-account-api.service`
|
||
installiert/aktiviert.
|
||
- Migrationen `0001_users`, `0002_users_password`, `0003_totp`,
|
||
`0003_password_tokens` real auf `tenant_acme` angewendet (fehlten
|
||
bisher dort) — `nexarch_core` hatte zusätzlich keine
|
||
CREATE-Berechtigung auf `tenant_acme`, Migrationen daher als
|
||
`postgres` ausgeführt (Betriebs-Erkenntnis, kein IAM-16-Defekt: DDL
|
||
läuft grundsätzlich privilegiert, DML über die Anwendungsrolle).
|
||
- Reale Grant-Lücke gefunden und behoben (gleiches Muster wie zuvor):
|
||
`nexarch_core` hatte keine Rechte auf `users`, `totp_credentials`,
|
||
`totp_recovery_codes`, `totp_policy`, `password_tokens` — `GRANT`
|
||
nachgezogen und über `information_schema.role_table_grants`
|
||
verifiziert.
|
||
- End-zu-Ende-Beweis: echter Testnutzer angelegt (`bcrypt`-Hash über
|
||
`auth.HashPassword`), Login-Fehlversuch und -Erfolg, geschützter
|
||
Endpunkt mit/ohne Cookie — alle Testdaten anschließend entfernt.
|
||
|
||
## Build/Test-Ergebnis (192.168.1.131)
|
||
|
||
```
|
||
go build ./... -> clean
|
||
go vet ./... -> clean
|
||
golangci-lint run ./cmd/account-api/... -> 0 issues
|
||
```
|
||
|
||
Keine neuen Go-Tests nötig (kein neuer Fachcode außer main.go, die
|
||
eigentliche Logik ist bereits durch IAM-08s eigene Tests abgedeckt).
|
||
|
||
## Gesamtergebnis
|
||
|
||
**Bestanden.** IAM-08 ist jetzt ein real laufender, über systemd
|
||
verwalteter Dienst — Voraussetzung für RBAC-05 und jede weitere
|
||
Auth-geschützte Core-GUI. Board-`dependsOn` von RBAC-05 wurde vor
|
||
dieser Umsetzung entsprechend korrigiert.
|