asdsad

temp/MODERIERTE_REGISTRIERUNG_KONZEPT.md

@@ -0,0 +1,213 @@
+# Moderierte Registrierung für desktop.kusche.berlin
+
+## Ziel
+
+Neue Nutzer sollen sich über die Login-Seite registrieren können, aber **nicht sofort** Zugriff auf den Desktop erhalten.
+
+Stattdessen soll der Ablauf so sein:
+
+1. Nutzer füllt Registrierungsformular aus.
+2. Anfrage wird als `ausstehend` gespeichert.
+3. Eine berechtigte Person prüft und genehmigt oder lehnt ab.
+4. Erst bei Genehmigung wird der LDAP-/NAS-kompatible Benutzer vollständig angelegt.
+5. Erst danach darf sich der Nutzer einloggen.
+
+## Warum der normale Keycloak-Registrierungsflow hier nicht reicht
+
+Der Standard-Registrierungsflow von Keycloak ist für euer Setup ungeeignet, weil:
+
+- Keycloak aktuell nur einen sehr schlanken LDAP-Eintrag erzeugt
+- die NAS aber deutlich mehr Attribute erwartet
+- Benutzer bei Standard-Registrierung sofort im Keycloak-Kontext existieren
+- eine nachträgliche manuelle Freigabe damit unnötig kompliziert wird
+
+Für eure Umgebung ist es sauberer, die Registrierung **vor** Keycloak bzw. **neben** Keycloak zu behandeln.
+
+## Empfohlene Architektur
+
+### 1. Eigenes Registrierungsformular im Projekt
+
+Nicht Keycloak `Registrieren` verwenden, sondern:
+
+- eigene Seite, z. B. `/auth/register`
+- eigenes Formular für:
+  - Benutzername
+  - Vorname
+  - Nachname
+  - E-Mail
+  - Passwort
+  - optional Begründung / Einladungscode / Referenz
+
+Diese Daten landen **nicht direkt im LDAP**, sondern zuerst in einer Warteschlange.
+
+### 2. Pending-Store für Registrierungsanfragen
+
+Die Registrierung wird lokal gespeichert, z. B.:
+
+- JSON-Datei in `data/registration-requests.json`
+- oder besser SQLite / kleine Datenbank
+
+Status je Eintrag:
+
+- `pending`
+- `approved`
+- `rejected`
+- `provisioned`
+- `failed`
+
+Zusätzlich speichern:
+
+- Zeitstempel
+- IP
+- Browser
+- gewünschter Benutzername
+- Mail
+- Vorname / Nachname
+- gehashter Passwort-Entwurf oder temporärer verschlüsselter Wert
+
+## Wichtig zum Passwort
+
+Passwörter dürfen **nicht im Klartext** in so einer Warteschlange liegen.
+
+Saubere Varianten:
+
+1. Passwort erst nach Freigabe setzen lassen
+2. oder verschlüsselt zwischenlagern
+3. oder nach Freigabe Einladungslink / Set-Password-Link senden
+
+Empfehlung:
+
+- bei Registrierung noch **kein finales Passwort** speichern
+- nach Freigabe bekommt der Nutzer einen Aktivierungslink
+- Passwort wird erst dann final gesetzt
+
+Das ist deutlich sauberer und sicherer.
+
+### 3. Admin-/Freigabe-Tool
+
+Es braucht ein internes Tool, z. B.:
+
+- Desktop-App `Benutzerfreigaben`
+- oder vorerst einfache Admin-Seite `/admin/registrations`
+
+Funktionen:
+
+- offene Registrierungen anzeigen
+- Details prüfen
+- genehmigen
+- ablehnen
+- Notiz hinterlegen
+
+Nur bestimmte Gruppen dürfen das:
+
+- `administrators`
+- optional `appadmin`
+
+### 4. Provisioning-Tool für LDAP/NAS
+
+Bei Genehmigung startet **euer eigenes Provisioning-Tool**.
+
+Dieses Tool erzeugt dann den Benutzer korrekt für die NAS, also mit allen nötigen Feldern:
+
+- passende `objectClass`
+- `uid`
+- `cn`
+- `sn`
+- `mail`
+- `uidNumber`
+- `gidNumber`
+- `homeDirectory`
+- `loginShell`
+- ggf. `displayName`
+- ggf. `gecos`
+- ggf. Apple-/Samba-/Shadow-Felder
+- passende Gruppenmitgliedschaften
+
+Genau dieser Teil sollte **nicht** Keycloak überlassen werden.
+
+### 5. Aktivierung für Keycloak-Login
+
+Nach erfolgreicher LDAP-Anlage:
+
+- Nutzerstatus im Pending-Store auf `provisioned`
+- Login ab dann erlaubt
+
+Optional zusätzlich:
+
+- Nutzer in bestimmte Startgruppen setzen
+- Mail zur Freischaltung versenden
+- Passwort-Setzen-Link generieren
+
+## Technische Varianten
+
+### Variante A: Registrierung komplett außerhalb von Keycloak
+
+Flow:
+
+1. Login-Seite hat Button `Registrieren`
+2. Button führt auf eure eigene Registrierungsseite
+3. Anfrage landet lokal im Pending-Store
+4. Admin genehmigt
+5. euer Tool legt LDAP-User korrekt an
+6. danach Login über Keycloak gegen LDAP
+
+Das ist die empfohlene Variante.
+
+### Variante B: Keycloak-Registrierung bleibt aktiv
+
+Flow:
+
+1. Nutzer registriert sich in Keycloak
+2. Benutzer wird dort oder im LDAP teilweise angelegt
+3. zusätzliche Freigabelogik blockiert Login
+
+Nachteile:
+
+- unsauberer Zustand
+- doppelte Logik
+- schwerer kontrollierbar
+- LDAP-/NAS-Kompatibilität bleibt problematisch
+
+Diese Variante würde ich nicht empfehlen.
+
+## Empfohlene Umsetzung für dieses Projekt
+
+### Phase 1
+
+- Keycloak-Registrierung im Login-Theme wieder entfernen oder deaktivieren
+- eigene Route `/auth/register`
+- einfache Ablage als JSON oder SQLite
+- Admin-Ansicht für Freigaben
+
+### Phase 2
+
+- eigenes LDAP-Provisioning-Skript / Service
+- Vergabe der fehlenden NAS-relevanten Attribute
+- Gruppen-Standardzuweisung
+
+### Phase 3
+
+- Aktivierungs-Mail oder Passwort-Setz-Link
+- Audit-Log
+- Benachrichtigungen für Administratoren
+
+## Konkrete Entscheidungsempfehlung
+
+Ja, wir können dafür ein Tool bauen.
+
+Die saubere Lösung ist:
+
+- **nicht** die Keycloak-Registrierung zu verbiegen
+- sondern eine **eigene moderierte Registrierung** im Projekt zu bauen
+- und erst nach Freigabe den LDAP-/NAS-Benutzer korrekt zu provisionieren
+
+## Nächster sinnvoller Schritt
+
+Als nächstes sollten wir bauen:
+
+1. `Registrieren` im Login nicht mehr auf Keycloak zeigen lassen
+2. neue Projektseite `/auth/register`
+3. lokaler `pending`-Store
+4. interne Admin-Seite für Freigaben
+
+Danach kommt das LDAP-Provisioning.