Single Sign-On (OIDC)¶

Benutzer melden sich über den Identity-Provider (IdP) der Organisation an statt mit Vesana-Passwort. Unterstützt wird jeder OpenID-Connect-fähige IdP — z. B. Microsoft Entra ID, Keycloak, Authentik, Google Workspace, Okta.

Eingerichtet wird SSO unter Admin → Anmeldung & Sicherheit → SSO (Super-Admin).

Wie es funktioniert¶

Die Login-Seite zeigt pro aktiviertem Provider einen Button „Anmelden mit …". Der Klick führt zum IdP; nach erfolgreicher Anmeldung landet der Benutzer direkt eingeloggt in Vesana (normale Browser-Session, wie beim Passwort-Login).
Der Passwort-Login bleibt immer verfügbar — eine IdP-Störung oder Fehlkonfiguration sperrt niemanden aus.
2FA übernimmt der IdP. Vesana-2FA-Pflichtregeln gelten für SSO-Konten nicht; MFA erzwingt man in Entra/Keycloak, wo es hingehört.
Technisch: Authorization Code Flow mit PKCE; das ID-Token wird gegen die Signatur-Schlüssel (JWKS) des IdP geprüft.

Einrichtung in 4 Schritten¶

Anwendung beim IdP registrieren (Web-Anwendung, „confidential"). Als Redirect-URI die URI eintragen, die Vesana auf der Provider-Karte anzeigt (https://<vesana-host>/api/v1/auth/sso/<id>/callback). Beim ersten Anlegen die URI nach dem Speichern aus der Karte kopieren und beim IdP nachtragen.
Provider in Vesana anlegen: Discovery-URL (…/.well-known/openid-configuration), Client-ID und Client-Secret eintragen. „Verbindung testen" prüft Erreichbarkeit und Signatur-Schlüssel sofort.
Benutzer-Zuordnung wählen:
Ohne JIT: nur Benutzer, deren Vesana-Benutzername dem IdP-Benutzernamen entspricht, können sich anmelden (bestehende lokale Konten werden beim ersten SSO-Login automatisch verknüpft).
Mit JIT-Provisioning: unbekannte IdP-Benutzer werden beim ersten Login automatisch angelegt — mit der Standard-Rolle oder per Gruppen-Mapping (IdP-Gruppe → Vesana-Rolle, erste Übereinstimmung gewinnt). JIT-Benutzer sehen alle Mandanten; die Rolle steuert die Rechte.
Testen: In einem privaten Fenster über den SSO-Button anmelden.

Provider-Beispiele¶

Microsoft Entra ID: App-Registrierung → Web → Redirect-URI eintragen → Zertifikate & Geheimnisse → Client-Secret erstellen. Discovery-URL: https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration. Für Gruppen-Mapping in der App-Registrierung „Groups claim" aktivieren (Gruppen kommen als Objekt-IDs — diese IDs ins Mapping eintragen).

Keycloak: Client anlegen (OpenID Connect, Client authentication an, Standard Flow an), Redirect-URI setzen, Secret aus dem Credentials-Tab. Discovery-URL: https://<keycloak>/realms/<realm>/.well-known/openid-configuration. Für Gruppen-Mapping dem Client einen „Group Membership"-Mapper (Claim groups, Full path aus) geben.

Authentik/Authelia/Okta: analog — OIDC-Provider/-App anlegen, Redirect-URI setzen, Discovery-URL übernehmen.

Details & Grenzen¶

Der Benutzername kommt aus dem Claim preferred_username (unter „Erweitert" änderbar, z. B. auf email).
SSO-Konten haben kein lokales Passwort und tragen in der Benutzerverwaltung eine SSO-Pille. Ein Admin kann jederzeit ein Passwort setzen — dann funktioniert zusätzlich der Passwort-Login (Break-Glass).
Provider löschen stellt alle verknüpften Benutzer auf lokalen Login zurück; ohne gesetztes Passwort bleibt das Konto bis zum Admin-Passwort-Reset gesperrt.
Abmelden beendet die Vesana-Session; die IdP-Session bleibt bestehen (kein Single Logout).