Relution als Identity Provider

Relution kann ab Version 26.5.0 als OpenID Connect / OAuth2 Identity Provider auftreten: Client-Anwendungen werden direkt in Relution registriert, sodass sich Benutzer:innen mit ihrem bestehenden Relution-Konto bei allen verbundenen Anwendungen anmelden können.

Funktionsumfang #

• Standardisierter Login-Ablauf über den Authorization-Code-Flow mit PKCE.
• Je Client konfigurierbare Scopes (profile, email, phone, relution) inklusive Zustimmungsbildschirm (Consent Screen) für die Benutzer:innen. Der Scope relution liefert Relution-spezifische Daten (z. B. Organisationszugehörigkeit).
• Übergreifende Abmeldung (Single Sign-Out): Sowohl RP-initiiertes Logout als auch OIDC Back-Channel Logout 1.0 werden unterstützt.
• Signaturschlüssel (JWK): Die Schlüssel, mit denen Tokens signiert werden, werden automatisch von Relution verwaltet und regelmäßig erneuert – hierum muss sich nicht gekümmert werden.

Signaturschlüssel widerrufen #

Die automatische Rotation deckt den normalen Betrieb vollständig ab. Für Ausnahmefälle (z. B. bei einem Sicherheitsvorfall) kann ein Signaturschlüssel zusätzlich manuell widerrufen (revoked) werden. Dabei ist zu beachten, dass verbundene Anwendungen (Relying Parties) den zuvor gültigen Schlüssel unter Umständen noch eine Zeit lang zwischengespeichert haben und Tokens damit erst nach Ablauf dieses Caches als ungültig erkannt werden.

Endpunkte für die Einbindung #

Am oberen Rand der Einstellungsseite Identity Provider werden die Issuer-URL sowie das Discovery-Dokument (.well-known/openid-configuration) bereitgestellt und können direkt kopiert werden. Über das Discovery-Dokument lassen sich bei Bedarf auch alle weiteren technischen Endpunkte (z. B. die JWKS-URI) nachschlagen, ohne dass diese manuell zusammengestellt werden müssten.

IdP-Verkettung #

Relution kann als Identity Provider auch mit einem vorgelagerten Identity Provider verkettet werden (z. B. Microsoft Entra ID → Relution → angebundene Anwendung).

Client registrieren #

Für jede angebundene Anwendung wird ein eigener Client angelegt:

• Name: Frei wählbar, wird Benutzer:innen auf dem Consent Screen angezeigt und dient Administrator:innen zur Unterscheidung mehrerer Clients.
• Client-ID und Client Secret: Werden automatisch generiert und von der anbindenden Anwendung (Relying Party) benötigt.
• Redirect-URI(s): Werden von der anbindenden Anwendung vorgegeben und müssen entsprechend hinterlegt werden.
• Scopes: Als erforderlich oder optional konfigurierte Scopes müssen von der anbindenden Anwendung im Login-Ablauf explizit angefragt werden.
• Admin-Zustimmung (Admin Consent): Die Zustimmung zu allen Scopes eines Clients kann bereits durch Administrator:innen im Voraus erteilt werden (nur als Ganzes, nicht je einzelnem Scope) – Benutzer:innen werden dann beim ersten Login bei der Anwendung nicht mehr über den Consent Screen befragt.

Sichtbarkeit je Organisationsebene #

Die Organisationsebene, auf der ein Client registriert wird, bestimmt, welche Benutzer:innen sich darüber anmelden können:

• Global: Alle Benutzer:innen im gesamten System können sich anmelden.
• Meta-Organisation: Alle Benutzer:innen der Meta-Organisation sowie ihrer Unterorganisationen können sich anmelden.
• Unterorganisation: Nur Benutzer:innen der jeweiligen Unterorganisation können sich anmelden.

Token-Vorschau #

Für die aktuelle Scope-Konfiguration eines Clients kann eine Vorschau der resultierenden Token-Claims eingesehen werden – so lässt sich vorab prüfen, welche Informationen eine verbundene Anwendung im Token erhalten würde.

Protokollierung #

Anmeldungen über den Identity Provider werden sowohl im Audit-Log als auch in der Login-Historie der jeweiligen Benutzer:innen erfasst.