117 lines
5.4 KiB
Markdown
117 lines
5.4 KiB
Markdown
# Phase 2: Authentication & Multi-Tenancy - Context
|
|
|
|
**Gathered:** 2026-06-18
|
|
**Status:** Ready for planning
|
|
|
|
<domain>
|
|
## Phase Boundary
|
|
|
|
Benutzerauthentifizierung (initialer Admin via Docker-ENV, manuelles CRUD, LDAP-Import), Login/Logout mit langlebiger Session, rollenbasierte Zugriffskontrolle (Super-Admin, Admin, User), Mandantenverwaltung mit PostgreSQL Row-Level Security. Kein SSO/OIDC, kein Payment — das kommt spaeter.
|
|
|
|
</domain>
|
|
|
|
<decisions>
|
|
## Implementation Decisions
|
|
|
|
### Login-Flow
|
|
- **D-01:** Login-Seite als Split-Screen (links Branding/Bild, rechts Login-Formular)
|
|
- **D-02:** Session-Dauer 30 Tage mit "Angemeldet bleiben" Option (Remember-me Checkbox)
|
|
- **D-03:** Passwort-Reset per E-Mail (Self-Service) + Admin kann Passwort manuell zuruecksetzen — erfordert SMTP-Konfiguration
|
|
- **D-04:** Login-Seite zeigt kein Sidebar/Header — eigenstaendiges Layout
|
|
|
|
### Admin-Setup
|
|
- **D-05:** Initialer Admin via Docker-ENV: TESSERA_ADMIN_USER, TESSERA_ADMIN_EMAIL, TESSERA_ADMIN_PASSWORD
|
|
- **D-06:** Force-Password-Change beim ersten Login optional konfigurierbar via ENV: TESSERA_FORCE_CHANGE=true/false
|
|
- **D-07:** Admin wird beim ersten Container-Start automatisch erstellt wenn er noch nicht existiert
|
|
|
|
### Mandanten-Modell
|
|
- **D-08:** Tenant-Zuordnung per Benutzer (kein URL-Unterschied, kein Subdomain-Routing) — Claude entscheidet technische Details
|
|
- **D-09:** Erstmal ein Mandant pro Benutzer — Multi-Tenant-Zugehoerigkeit kommt spaeter
|
|
- **D-10:** Super-Admin Rolle existiert: kann alle Mandanten sehen/verwalten, Mandanten anlegen, zwischen ihnen wechseln, globale Einstellungen aendern
|
|
- **D-11:** RLS auf PostgreSQL-Ebene — Tenant-ID wird per Request-Context gesetzt
|
|
|
|
### RBAC
|
|
- **D-12:** Drei Rollen: Super-Admin (plattformweit), Admin (mandantenspezifisch), User (mandantenspezifisch)
|
|
- **D-13:** Super-Admin wird ueber den initialen Admin-Account angelegt (erster Account = Super-Admin)
|
|
|
|
### LDAP-Import
|
|
- **D-14:** Manueller Button ("LDAP synchronisieren") in der Benutzerverwaltung + konfigurierbares Auto-Sync-Intervall
|
|
- **D-15:** Benutzer die aus LDAP geloescht werden: in Tessera deaktiviert (nicht geloescht)
|
|
- **D-16:** Feld-Mapping konfigurierbar in den LDAP-Einstellungen, Standard-Defaults vorausgewaehlt: displayName → Name, mail → E-Mail, sAMAccountName → Username
|
|
- **D-17:** Custom-Felder muessen auch gemappt werden koennen (erweiterbare Mapping-Tabelle)
|
|
- **D-18:** LDAP-Konfiguration pro Mandant (Server-URL, Base-DN, Bind-User, Filter, Mapping)
|
|
|
|
### Claude's Discretion
|
|
- Tenant-Identifikation technisch (JWT-Claim, Middleware-Pattern, Header) — Benutzer hat "du entscheidest" gewaehlt
|
|
- JWT vs. Session-Cookie Implementierung — soll sicher und langlebig sein
|
|
- SMTP-Konfiguration Struktur (ENV-Variablen fuer Mailserver)
|
|
- Keycloak-Nutzung: Research soll entscheiden ob eigene Auth oder Keycloak sinnvoller ist fuer diesen Scope
|
|
|
|
</decisions>
|
|
|
|
<canonical_refs>
|
|
## Canonical References
|
|
|
|
**Downstream agents MUST read these before planning or implementing.**
|
|
|
|
### Projekt-Kontext
|
|
- `.planning/PROJECT.md` — Gesamtprojekt, Core Value, Constraints
|
|
- `.planning/REQUIREMENTS.md` — Phase-2-Requirements: AUTH-01..06, TNNT-01..03
|
|
- `.planning/ROADMAP.md` — Phase-Ziel und Success Criteria
|
|
|
|
### Research
|
|
- `.planning/research/STACK.md` — Technologie-Stack (Keycloak 26.6 empfohlen, Prisma 7, PostgreSQL RLS)
|
|
- `.planning/research/ARCHITECTURE.md` — Auth-Modul, Tenant-Modul, RLS-Pattern
|
|
- `.planning/research/PITFALLS.md` — LDAP als Auth-Antipattern, Tenant-Context in Async, RLS von Tag 1
|
|
|
|
### Vorherige Phase
|
|
- `.planning/phases/01-foundation-portal-shell/01-CONTEXT.md` — Design-Entscheidungen Phase 1
|
|
- `.planning/phases/01-foundation-portal-shell/01-01-SUMMARY.md` — Walking Skeleton (Prisma-Schema, NestJS-Struktur)
|
|
- `.planning/phases/01-foundation-portal-shell/01-02-SUMMARY.md` — Portal Shell (Header User-Placeholder, Sidebar User-Placeholder)
|
|
|
|
</canonical_refs>
|
|
|
|
<code_context>
|
|
## Existing Code Insights
|
|
|
|
### Reusable Assets
|
|
- `apps/api/src/prisma/schema.prisma` — Prisma-Schema mit Tenant-Model-Grundlage aus Phase 1
|
|
- `apps/api/src/health/health.controller.ts` — NestJS Controller-Pattern als Vorlage
|
|
- `apps/web/src/components/layout/header.tsx` — User-Avatar-Placeholder der mit Auth verdrahtet werden muss
|
|
- `apps/web/src/components/layout/sidebar-footer.tsx` — User-Info-Placeholder der mit Auth verdrahtet werden muss
|
|
|
|
### Established Patterns
|
|
- NestJS mit Prisma-Client fuer DB-Zugriff
|
|
- Next.js App Router mit Server Components + Client Components
|
|
- next-intl fuer i18n (alle neuen Seiten muessen t() verwenden)
|
|
- Zustand-Stores mit Persist-Middleware fuer Client-State
|
|
|
|
### Integration Points
|
|
- Login-Seite braucht eigenes Layout (kein AppShell)
|
|
- Auth-Guard muss alle bestehenden Routen schuetzen
|
|
- Header und Sidebar-Footer muessen den eingeloggten Benutzer anzeigen
|
|
- SMTP-Konfiguration als Docker-ENV-Variablen
|
|
|
|
</code_context>
|
|
|
|
<specifics>
|
|
## Specific Ideas
|
|
|
|
- Split-Screen Login: links Tessera-Branding mit gelber Primaerfarbe (#ffed00), rechts Formular auf weissem/dunklem Hintergrund
|
|
- Super-Admin Dashboard: eigener Bereich zum Verwalten aller Mandanten (Mandanten-Liste, Benutzer-Uebersicht)
|
|
- LDAP-Einstellungen: eigene Seite in den Admin-Einstellungen mit Test-Connection-Button und Mapping-Editor
|
|
|
|
</specifics>
|
|
|
|
<deferred>
|
|
## Deferred Ideas
|
|
|
|
None — discussion stayed within phase scope
|
|
|
|
</deferred>
|
|
|
|
---
|
|
|
|
*Phase: 2-Authentication & Multi-Tenancy*
|
|
*Context gathered: 2026-06-18*
|