Zum Inhalt

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.

Vorschau-Funktion — standardmäßig aus

SSO ist eine Vorschau-Funktion: auf einer frischen Instanz ist es ausgeschaltet, der Admin-Reiter erscheint nicht und die Anmeldeseite zeigt keine SSO-Knöpfe. Freischalten unter Admin → System → Vorschau-Funktionen (nur Super-Admins). Wer vor dem Update schon einen Provider eingerichtet hatte, behält SSO eingeschaltet — auch bei einem abgeschalteten Provider, damit Konten ohne Passwort nicht ausgesperrt werden.

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

Firma mit Windows-Domäne, aber ohne Identity-Provider?

Dann direkt das Active Directory anbinden: Anmeldung mit Active Directory (LDAP) — Anmeldung mit dem Domänenkonto über die normale Anmeldemaske, ohne Keycloak/Entra dazwischen.

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. Für die Anmeldung über den Identity-Provider gelten Vesana-2FA-Pflichtregeln nicht; MFA erzwingt man in Entra/Keycloak, wo es hingehört. Meldet sich ein SSO-Konto dagegen mit einem (vom Admin gesetzten) Passwort an, gilt die lokale 2FA-Pflicht.
  • Technisch: Authorization Code Flow mit PKCE; das ID-Token wird gegen die Signatur-Schlüssel (JWKS) des IdP geprüft.

Einrichtung in 4 Schritten

  1. 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). Läuft die Instanz auf einem anderen HTTPS-Port als 443, steht der Port in der URI (https://<vesana-host>:8443/…). Beim ersten Anlegen die URI nach dem Speichern aus der Karte kopieren und beim IdP nachtragen.
  2. 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.
  3. Benutzer-Zuordnung wählen:
  4. Ohne JIT: nur Benutzer, die in Vesana schon ein Konto haben, können sich anmelden. Ein vorhandenes lokales Konto verknüpft Vesana beim ersten SSO-Login nur, wenn Lokale Konten verknüpfen an ist (Vesana-Benutzername = IdP-Benutzername; meldet der IdP die E-Mail-Adresse ausdrücklich als unverifiziert, wird nicht verknüpft). Der Schalter ist für neue Provider aus; dann endet ein Login, dessen Benutzername ein lokales Konto trifft, mit einer Meldung, und es entsteht weder eine Verknüpfung noch ein zweites Konto. Schalte ihn nur an, wenn der IdP den Benutzernamen und die E-Mail-Adresse prüft: wo Benutzer ihren Namen selbst wählen, könnte sonst jemand ein fremdes Konto samt Rechten übernehmen. Lokale Super-Admins werden nie verknüpft, bereits verknüpfte Konten melden sich unabhängig vom Schalter weiter an.
  5. 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.
  6. Teams aus Provider-Gruppen (unabhängig von JIT): IdP-Gruppe → Vesana-Team. Bei jedem Login kommt der Benutzer in die Teams seiner Gruppen und verliert Teams, deren Gruppe fehlt. Von Hand gesetzte Team-Mitgliedschaften bleiben unberührt.
  7. 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 abschalten oder löschen beendet sofort alle laufenden Vesana-Sitzungen seiner Benutzer. Löschen stellt sie zusätzlich 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).