Files

T

sysops 3b3991f54f IAM-16: login-account-dienst-starten

- 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

2026-08-30 21:18:57 +02:00

4.0 KiB

Raw Blame History

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.

4.0 KiB Raw Blame History Unescape Escape