diff --git a/Doku/plans/registrierung-und-login.md b/Doku/plans/registrierung-und-login.md new file mode 100644 index 0000000..ae388a3 --- /dev/null +++ b/Doku/plans/registrierung-und-login.md @@ -0,0 +1,102 @@ +# Plan: Registrierung und Anmeldung (Entwurf) + +Stand 2026-10-31, noch nicht umgesetzt. Ziel: ein Zwischending zwischen „jeder darf sich registrieren“ und „für jede Person einen Einladungscode erzeugen“, dazu bequemere Anmeldung. + +## Heute + +- `ALLOW_REGISTRATION` bzw. Admin-Schalter „offene Registrierung“: jeder kann ein Konto anlegen. +- Sonst nur mit Einladungscode (optional an eine E-Mail-Adresse und eine Organisation gebunden, einmal verwendbar, mit Ablaufdatum). +- Anmeldung nur mit E-Mail/Benutzername und Passwort (dazu API-Keys für Webhooks). + +## 1. Registrierungsmodus statt Ja/Nein + +Ein Modus ersetzt den Schalter „offene Registrierung“: + +| Modus | Verhalten | +|---|---| +| `closed` | Nur mit Einladungscode (wie heute ohne offene Registrierung). | +| `approval` | Jeder kann sich registrieren, das Konto ist aber **gesperrt, bis ein Admin es freigibt**. | +| `domain` | Registrierung nur mit E-Mail-Adressen bestimmter Endungen (z. B. `@firma.de, @familie-dach.de`), sofort aktiv. | +| `domain+approval` | Erlaubte Endungen sofort aktiv, alle anderen warten auf Freigabe. | +| `open` | Jeder, sofort aktiv (wie heute). | + +Einladungscodes funktionieren in jedem Modus und überspringen Freigabe und Endungsprüfung. + +**Freigabe durch Admin** +- Neue Konten im Modus `approval` werden mit `is_active = 0` und einem Status „wartet auf Freigabe“ angelegt (eigenes Feld, damit „gesperrt“ und „wartet“ unterscheidbar bleiben). +- Die Person sieht nach der Registrierung: „Dein Konto wird geprüft. Du bekommst eine E-Mail, sobald es freigeschaltet ist.“ Anmelden geht bis dahin nicht (gleiche Meldung). +- Admins bekommen eine Benachrichtigung über die vorhandenen Kanäle (E-Mail/Push, neues Ereignis „Registrierung wartet“) und sehen in der Benutzerverwaltung oben eine Liste **„Wartet auf Freigabe“** mit Freigeben / Ablehnen. Ablehnen löscht das Konto. +- Bei Freigabe geht eine E-Mail im bekannten Layout an die Person („Dein Konto ist freigeschaltet“ mit Knopf zur App). +- Ohne SMTP funktioniert alles, nur ohne E-Mails. + +**E-Mail-Endungen** +- Liste von Domains, Vergleich ohne Groß-/Kleinschreibung auf den Teil nach `@` (keine Subdomains, außer ausdrücklich `*.firma.de`). +- Optional: **E-Mail-Adresse bestätigen** per Link (wie Passwort vergessen, gleiche Token-Technik), bevor das Konto aktiv wird. Sonst kann jeder `chef@firma.de` eintippen. Bei `domain` sollte die Bestätigung Pflicht sein, wenn SMTP eingerichtet ist. + +**Missbrauch** +- Gleiche Bremse wie beim Login (Anfragen pro IP), dazu höchstens N wartende Registrierungen gleichzeitig (z. B. 50), danach „gerade keine Registrierung möglich“. +- In der Demo bleibt Registrierung aus. + +## 2. Einstellungen: Admin-Oberfläche oder Umgebungsvariablen + +Damit die Admin-Einstellungen nicht überladen werden: + +- **Admin-Oberfläche:** nur der Modus (Auswahlfeld) und darunter, je nach Modus, das Feld für die erlaubten Endungen. Die Liste „Wartet auf Freigabe“ steht in der Benutzerverwaltung, nicht in den Einstellungen. +- **Umgebungsvariablen** (gewinnen, wenn gesetzt; das Feld in der Oberfläche ist dann gesperrt mit Hinweis „über die Umgebung festgelegt“ – so wie heute bei SMTP): + + ```env + REGISTRATION_MODE=domain+approval # closed | approval | domain | domain+approval | open + REGISTRATION_DOMAINS=firma.de,familie-dach.de + REGISTRATION_VERIFY_EMAIL=true # Bestätigungslink vor Aktivierung + ``` +- `ALLOW_REGISTRATION=true` bleibt als Alias für `REGISTRATION_MODE=open` erhalten. + +## 3. Anmelden mit anderen Konten + +### a) OpenID Connect (empfohlen statt „nur Google“) + +Ein allgemeiner OIDC-Login deckt Google, Microsoft, Apple und vor allem **selbst gehostete Anbieter** ab: Authentik, Keycloak, Authelia – und **Gitea/Forgejo selbst** kann OIDC-Anbieter sein. Für ein Homelab ist das meist nützlicher als Google. + +- Konfiguration nur per Umgebung (Geheimnisse gehören nicht in die Datenbank-Oberfläche): + ```env + OIDC_ISSUER=https://git.dsit.me/ # oder https://accounts.google.com + OIDC_CLIENT_ID=… + OIDC_CLIENT_SECRET=… + OIDC_BUTTON_LABEL=Mit Gitea anmelden + OIDC_ALLOWED_DOMAINS=firma.de # optional, sonst gilt der Registrierungsmodus + OIDC_AUTO_CREATE=true # neues Konto beim ersten Login anlegen (Modus/Freigabe gelten) + ``` +- Ablauf: Authorization Code Flow mit PKCE, `state` und `nonce`; Rückkehr auf `BASE_URL/api/v1/auth/oidc/callback`. Konten werden über `iss`+`sub` verknüpft (neue Tabelle), nicht nur über die E-Mail. +- Besteht schon ein Konto mit derselben, vom Anbieter **bestätigten** E-Mail, wird es nach Passwortabfrage verknüpft (kein stilles Übernehmen fremder Konten). +- Danach normale MindSift-Sitzung (wie heute), Abmelden bleibt lokal. +- Passwort-Login bleibt daneben möglich; optional `PASSWORD_LOGIN=false`, wenn nur noch OIDC gewünscht ist (Admin-Notzugang beachten). + +### b) Anmeldung über den Mailserver (wie die SMTP-Quelle in Gitea) + +Gitea prüft dabei E-Mail und Passwort, indem es sich damit am Mailserver anmeldet (SMTP AUTH). Klappt das, ist die Person echt; das Konto wird beim ersten Mal angelegt. + +- Konfiguration per Umgebung: + ```env + MAIL_LOGIN_HOST=mail.firma.de + MAIL_LOGIN_PORT=587 # STARTTLS oder 465 mit TLS – nie unverschlüsselt + MAIL_LOGIN_DOMAINS=firma.de # nur diese Adressen werden am Mailserver geprüft + ``` +- Für solche Konten speichert MindSift **kein** Passwort; jede Anmeldung fragt den Mailserver. Ändert sich das Mailpasswort, gilt automatisch das neue. +- Nachteile: Das Mailpasswort läuft durch MindSift (nur über TLS, nie loggen); fällt der Mailserver aus, kann sich niemand anmelden; Login-Bremse ist Pflicht, damit MindSift nicht zum Passwort-Rateautomaten für den Mailserver wird. Viele Anbieter (Google, Microsoft 365) erlauben SMTP AUTH mit dem normalen Passwort gar nicht mehr – sinnvoll ist das vor allem mit einem eigenen Mailserver. +- Technisch klein: Der SMTP-Code für den Versand (`internal/api/mail.go`, inkl. PLAIN/LOGIN) existiert schon. + +Empfehlung: **erst OIDC**, Mailserver-Login nur wenn ein eigener Mailserver ohne OIDC-Anbieter das Ziel ist. + +## Reihenfolge und Aufwand (grob) + +1. Registrierungsmodus mit Freigabe und Endungen, Umgebungsvariablen, Admin-Liste „Wartet auf Freigabe“, E-Mails – mittel. +2. E-Mail-Bestätigung per Link – klein (Technik wie Passwort vergessen). +3. OIDC-Login – mittel (Bibliothek `coreos/go-oidc` + `golang.org/x/oauth2`, neue Tabelle für verknüpfte Konten, Knopf auf der Anmeldeseite). +4. Mailserver-Login – klein bis mittel, optional. + +## Offene Fragen + +- Sollen Admins bei jeder wartenden Registrierung benachrichtigt werden oder reicht ein Zähler in der Benutzerverwaltung? +- Neue Konten per Endung automatisch einer Organisation zuordnen (z. B. `@firma.de` → Organisation „Firma“)? +- Welcher OIDC-Anbieter zuerst: Gitea, Google, Authentik …? +- Soll ein abgelehnter Antrag gesperrt bleiben (gleiche Adresse kann es nicht erneut versuchen) oder einfach gelöscht werden?