msolarczekandClaude Opus 5
c8e6f30a27
Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.8 KiB
3.8 KiB
Ü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
- 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.
- 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)
- Onboarding: Pflichtlektüre
docs/HANDOVER-DEV.md→docs/SPEC.md→docs/STAND-dev-branch.md→ FEINDESIGN → KONZEPT. Dev-Setup + Gate (§10 im FEINDESIGN). - WS0 Fundament als Pairing (Lead + je 1 Dev):
Identity-Modell, Schema-Recut, Migration,TENANT_MODELS, Reseed. Blocker für fast alles Weitere. - Danach parallel: WS1 (Auth-Kern), WS3 (Einladung), WS4 (Passwort/MFA an Identity), WS6 (Seed).
Die 5 „Goldenen Regeln" (nicht verhandelbar)
User.id= Mitgliedschaft, stabil lassen; Auth-Felder leben aufIdentity.Identityist global, nicht inTENANT_MODELS, keintenant_id, keine RLS-Policy.- Genau ein aktiver Mandant pro Session; server-autoritativ; bei Wechsel re-validieren.
- Keine „Passwort direkt setzen"-Anlage mehr — nur Einladung.
- 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()undrequirePlatformFullAdmin— alles stabile Flächen. Ein Berührungspunkt: die geteilte Dateisrc/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-ffnachdev→ Gate grün (tsc/lint/build + allescripts/test-*.ts) → Push auf beide Remotes (origingit.certvia.de +local-gitea) →docs/STAND-dev-branch.mdpflegen.
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.