desktop/temp/MODERIERTE_REGISTRIERUNG_KONZEPT.md

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.