craftvia/docs/UEBERGABE-identity-mandanten.md

Übergabe — Umbau „Zentrale Identität + Mandanten-Mitgliedschaften" (certvia)

Kurzübergabe für Team-Lead + PM + neue Entwickler. Produkt: certvia (ISMS-Tool). Branch: feature/identity-mandanten.

Worum es geht

Eine Person soll sich mit einem Login/Passwort/MFA anmelden und danach wählen, in welchem Mandanten sie arbeitet — mit je Mandant unterschiedlichen Rollen. Heute ist jeder Nutzer fest an genau einen Mandanten gebunden (eigenes Passwort/MFA je Mandant). Umbau nach Option C: globale Identity (Anmeldung) + bestehende per-Mandant-User-Zeilen als „Mitgliedschaften".

Die zwei Dokumente

1. KONZEPT-identity-mandanten.md — Entscheidungsvorlage (fachlich, warum/was). Enthält die getroffenen Entscheidungen A–E, Two-Step-Login, Passphrasen, MFA-Matrix, die vier Anlage-Flows, Sicherheitsbetrachtung.
2. FEINDESIGN-identity-mandanten.md — umsetzbarer Bauplan (technisch): Zieldatenmodell, Session-Shape, Flows, 7 Workstreams, 6 Meilensteine, Risiken, DoD, Onboarding, Aufwand (≈ 47–73 PT / ≈ 5–7 Wochen).

Getroffene Entscheidungen (fix)

A	B	C	D	E
MFA beim Login (2-stufig: erst Passwort, dann MFA)	Reset-Hoheit → Self-Service + Plattform (Mandanten-Admin verliert MFA-/Passwort-Reset)	Einladung als Standard-Anlage	Migration entfällt (nur Testdaten → Reseed)	Plattform-Admins getrennt (platform_admins)

Womit das Team startet (M0 → M1)

1. Onboarding: Pflichtlektüre docs/HANDOVER-DEV.md → docs/SPEC.md → docs/STAND-dev-branch.md → FEINDESIGN → KONZEPT. Dev-Setup + Gate (§10 im FEINDESIGN).
2. WS0 Fundament als Pairing (Lead + je 1 Dev): Identity-Modell, Schema-Recut, Migration, TENANT_MODELS, Reseed. Blocker für fast alles Weitere.
3. Danach parallel: WS1 (Auth-Kern), WS3 (Einladung), WS4 (Passwort/MFA an Identity), WS6 (Seed).

Die 5 „Goldenen Regeln" (nicht verhandelbar)

1. User.id = Mitgliedschaft, stabil lassen; Auth-Felder leben auf Identity.
2. Identity ist global, nicht in TENANT_MODELS, kein tenant_id, keine RLS-Policy.
3. Genau ein aktiver Mandant pro Session; server-autoritativ; bei Wechsel re-validieren.
4. Keine „Passwort direkt setzen"-Anlage mehr — nur Einladung.
5. MFA/Passwort gehören der Identity — kein Mandanten-Admin-Reset.

Warum der Umbau überschaubar bleibt

Weil User.id und die Semantik von session.user.tenantId (= aktiver Mandant) erhalten bleiben, sind ~356 dbForTenant()-Stellen, alle 6 Owner-FKs und das RLS-Modell unberührt. Der Umbau konzentriert sich auf Login, Session-Aufbau, Mandantenauswahl und Nutzer-Lifecycle.

Koordination mit laufender Arbeit

• Richtlinien-Upload im Adminportal (parallel in Arbeit) ist funktional nicht betroffen: er hängt nur an moduleGuard("policies"), session.user.tenantId, session.user.id, dbForTenant() und requirePlatformFullAdmin — alles stabile Flächen. Ein Berührungspunkt: die geteilte Datei src/app/(platform)/admin/[id]/page.tsx (Policy-Upload an der Module-Karte, Identity-Umbau an der Benutzerverwaltung) → nur Merge-Koordination, kein funktionaler Konflikt. Empfehlung: WS3/WS-UI und der Policy-Upload-Stream stimmen Reihenfolge auf dieser Datei ab.
• DevOps: Feature-Branch → git merge --no-ff nach dev → Gate grün (tsc/lint/build + alle scripts/test-*.ts) → Push auf beide Remotes (origin git.certvia.de + local-gitea) → docs/STAND-dev-branch.md pflegen.

Offen für PM-Entscheidung (kein Blocker fürs Feindesign)

• Team-Besetzung/Startdatum, Sprint-Zuschnitt entlang M1–M6.
• Phase-2-Punkte (per-Mandant „immer Step-up", E-Mail-Änderung als Identity-Op, evtl. PlatformAdmin-Konsolidierung) — bewusst zurückgestellt.