# 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.