214 lines
5.2 KiB
Markdown
214 lines
5.2 KiB
Markdown
# 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.
|