Single Sign On (SSO)

Unterstützung für OAuth Authentifizierung

Localmind unterstützt mehrere Formen der SSO-Authentifizierung:

• OAuth2
• Google
• Microsoft
• OIDC
• Vertrauenswürdige Header
• OAuth
• LDAP (deprecated)

Um Single Sign On zu aktivieren, müssen die SSO-Zugangsdaten an Localmind zur Einrichtung auf sicherem Wege übermittelt werden.

Beispiele

Google OAuth

Schritt 1: OAuth-Client bei Google erstellen

1. Erstellen Sie über die Google Cloud Console ein neues Projekt oder verwendet ein bestehendes.
2. Legen Sie in der Google Cloud Console unter APIs & Dienste → Anmeldedaten (engl. Credentials) einen OAuth 2.0-Client für eine Webanwendung an. Eine genaue Anleitung finden Sie hier.
3. Die benötigte Weiterleitungs-URL erhalten Sie von uns auf Anfrage.
4. Notieren Sie sich folgende Informationen aus der Google-Konsole:
   • GOOGLE_CLIENT_ID (Client-ID)
   • GOOGLE_CLIENT_SECRET (Client-Secret)

Schritt 2: Diese Werte müssen an Localmind übermittelt werden.

Microsoft OAuth

Schritt 1: OAuth-Client bei Microsoft erstellen

1. Erstellen Sie über das Microsoft Azure Admin Center eine neue App-Registrierung für eine Web-Anwendung. Eine genaue Anleitung findet ihr hier.
2. Die benötigte Weiterleitungs-URL erhalten Sie auf Anfrage
3. Notieren Sie sich:
   • MICROSOFT_CLIENT_ID (Application (client) ID)
   • MICROSOFT_CLIENT_SECRET (Client secret)
   • MICROSOFT_CLIENT_TENANT_ID (Directory (tenant) ID)

Schritt 2: Diese Werte müssen an Localmind übermittelt werden.

Generisches OAuth

Jeder Authentifizierungsanbieter, der OIDC unterstützt, kann konfiguriert werden.

Das E-Mail-Claim ist erforderlich, während die Claims für **Name** und **Bild** verwendet werden, falls verfügbar.

Die erlaubte Redirect-URI sollte `<ihre_localmind_url>/oauth/oidc/callback` enthalten.

Erforderliche Werte, welche an uns übermittelt werden müssen:

1. OAUTH_CLIENT_ID – OIDC Client ID
2. OAUTH_CLIENT_SECRET – OIDC Client Secret
3. OPENID_PROVIDER_URL – OIDC-Well-Known-URL (z. B. `https://accounts.google.com/.well-known/openid-configuration`)
4. OAUTH_SCOPES – Angeforderte Scopes (Standard: `openid email profile`)

OAuth Rollenverwaltung

Jeder OAuth-Anbieter, der Rollen im Zugriffstoken zurückgeben kann, kann zur Verwaltung von Rollen in Localmind verwendet werden. Folgende Variablen können konfiguriert werden:

• OAUTH_ROLES_CLAIM – Claim, der die Rollen enthält (Standard: roles). Kann auch geschachtelt sein, z. B. user.roles.
• OAUTH_ALLOWED_ROLES – Kommagetrennte Liste der Rollen, die sich anmelden dürfen (z.B. Rolle user,editor).
• OAUTH_ADMIN_ROLES – Kommagetrennte Liste der Rollen, die sich als Admin anmelden dürfen (z.B. Rolle admin,organization_admin).

ℹ️ Hinweis: Wenn die Rolle eines angemeldeten Nutzers geändert wird, muss dieser sich aus- und wieder einloggen, um die neue Rolle zu erhalten.

Vertrauenswürdige Header

Localmind AI kann die Authentifizierung an einen Reverse Proxy delegieren, der die Benutzerdaten in HTTP-Headern übermittelt.

Generische Konfiguration

Wenn ein Trusted Email Header gesetzt ist, wird Localmind AI den Wert des angegebenen Headers als Benutzer-E-Mail-Adresse verwenden und eine automatische Registrierung sowie Anmeldung durchführen.

Beispiel:

Wenn der Trusted Email Header auf X-User-Email gesetzt ist und eine HTTP-Anfrage mit dem Header X-User-Email: example@example.com eingeht, wird der Nutzer mit example@example.com authentifiziert.

Optional kann auch ein Trusted Name Header gesetzt werden, um den Namen des Benutzers festzulegen (wenn dieser neu erstellt wird).