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 mit ihrem bestehenden Relution-Konto bei allen verbundenen Anwendungen anmelden können.

Die Konfiguration erfolgt unter Einstellungen → Identitätsanbieter. Die Seite ist nur mit der Berechtigung zum Lesen von IdP-Clients sichtbar; für das Registrieren, Bearbeiten und Löschen von Clients sind die jeweiligen Berechtigungen erforderlich.

Funktionsumfang #

• Standardisierter Login-Ablauf über den Authorization-Code-Flow mit PKCE; Refresh-Token werden unterstützt.
• Multi-Faktor-Authentifizierung: Ab Relution 26.5.5 durchläuft auch die Anmeldung an angebundenen Anwendungen die Multi-Faktor-Authentifizierung →. Benutzer mit eingerichteter oder erzwungener MFA bestätigen während der Anmeldung den zweiten Faktor bzw. richten ihn ein und werden danach zur Anwendung zurückgeleitet.
• Je Client konfigurierbare Scopes (profile, email, phone, relution) inklusive Zustimmungsbildschirm (Consent Screen) für die Benutzer. Der Scope relution liefert Relution-spezifische Daten (z. B. Organisationszugehörigkeit). Der Scope phone kann zwar aktiviert werden, liefert derzeit aber keine zusätzlichen Claims (z. B. keine Telefonnummer).
• Übergreifende Abmeldung (Single Sign-Out): Sowohl RP-initiiertes Logout als auch OIDC Back-Channel Logout 1.0 werden unterstützt. Ein RP-initiiertes Logout beendet auch die Relution-Sitzung im Browser.
• Widerruf bei Kontoänderungen: Ab Relution 26.5.5 widerruft Relution alle Autorisierungscodes, Access- und Refresh-Tokens eines Benutzers, sobald sein Passwort geändert oder sein Konto gesperrt oder deaktiviert wird. Die angebundenen Anwendungen müssen den Benutzer danach neu anmelden; erteilte Zustimmungen bleiben erhalten. Beim Löschen des Benutzers werden zusätzlich seine Zustimmungen entfernt. Außerdem wird bei jeder Token-Ausstellung, auch beim Erneuern per Refresh-Token, geprüft, ob der Benutzer der Organisation noch angehört. Nach dem Update auf Relution 26.5.5 oder neuer ist in den angebundenen Anwendungen einmalig eine erneute Anmeldung erforderlich.
• Signaturschlüssel (JWK): Die Schlüssel, mit denen Tokens signiert werden, werden automatisch von Relution verwaltet und regelmäßig erneuert (ein aktiver Schlüssel wird nach vier Monaten durch einen neuen abgelöst) – hierum muss sich nicht gekümmert werden.

Signaturschlüssel rotieren und widerrufen #

Die Signaturschlüssel werden im Bereich Signaturschlüssel der Seite Einstellungen → Identitätsanbieter verwaltet. Dieser Bereich steht nur in der globalen Organisation zur Verfügung; in Meta- und Unterorganisationen wird er nicht angezeigt.

Die automatische Rotation deckt den normalen Betrieb vollständig ab. Für Ausnahmefälle (z. B. bei einem Sicherheitsvorfall) stehen zwei manuelle Eingriffe zur Verfügung:

• Schlüssel rotieren: Es wird ein neuer aktiver Schlüssel erstellt, der bisherige wird außer Betrieb genommen (Status Wird abgelöst). Bereits ausgestellte Tokens bleiben bis zu ihrem Ablauf gültig. Eine erneute Rotation ist frühestens fünf Minuten nach der letzten möglich.
• Widerrufen: Der ausgewählte Schlüssel wird sofort aus dem veröffentlichten Schlüsselsatz entfernt. 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 #

Im Bereich Anbieter oben auf der Seite Einstellungen → Identitätsanbieter werden die Aussteller-URL (Issuer-URL), das Discovery-Dokument (.well-known/openid-configuration) und die JWKS-URI angezeigt und können direkt kopiert werden. Weitere technische Endpunkte (z. B. der Token-Endpunkt) lassen sich bei Bedarf über das Discovery-Dokument ermitteln.

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 über Client registrieren ein eigener Client angelegt:

• Client-Name: Frei wählbar, wird Benutzern auf dem Consent Screen angezeigt und dient Administratoren zur Unterscheidung mehrerer Clients.
• ClientID und Client-Geheimnis (Client Secret): Werden automatisch generiert und von der anbindenden Anwendung (Relying Party) benötigt. Die Anwendung authentifiziert sich damit per client_secret_basic oder client_secret_post. Das Client-Geheimnis wird nur einmal direkt nach dem Anlegen des Clients angezeigt und muss dann kopiert werden; es lässt sich später nicht erneut abrufen. Geht es verloren, kann in der Liste Registrierte Clients über Geheimnis neu generieren ein neues erzeugt werden (ebenfalls nur einmal angezeigt). Dabei wird das bisherige Geheimnis ungültig und alle bestehenden Token des Clients werden widerrufen.
• Aktiviert: Ein deaktivierter Client lehnt neue Anmeldungen und das Erneuern von Tokens per Refresh-Token ab.
• PKCE erforderlich: Standardmäßig aktiviert. Unterstützt die anbindende Anwendung kein PKCE, kann die Option für den jeweiligen Client deaktiviert werden.
• Umleitungs-URIs (Redirect-URIs): Werden von der anbindenden Anwendung vorgegeben und müssen entsprechend hinterlegt werden.
• Abmelde-Rückleitungsadressen (Post-Logout-Redirect-URIs): Adressen, zu denen die Anwendung den Browser nach einem RP-initiierten Logout umleiten darf.
• Back-Channel-Abmelde-URL: Ist sie gesetzt, benachrichtigt Relution die Anwendung im Hintergrund, sobald die Sitzung des Clients endet. Bleibt leer, wenn die Anwendung kein Back-Channel Logout unterstützt.
• Access-Token-TTL und Refresh-Token-TTL: Gültigkeitsdauer der ausgestellten Tokens. Im Formular sind für neue Clients 5 Minuten bzw. 1 Tag vorbelegt; zulässig sind 1 bis 60 Minuten für Access-Tokens und 1 bis 90 Tage für Refresh-Tokens. Bei Passwortänderung, Sperre, Deaktivierung oder Löschung des Benutzers werden die Tokens unabhängig von der TTL vorzeitig widerrufen (siehe Widerruf bei Kontoänderungen unter Funktionsumfang).
• Berechtigungen (Scopes): Je Scope wird Deaktiviert, Optional oder Erforderlich gewählt. Standardmäßig sind profile und email erforderlich, phone und relution deaktiviert. openid ist immer aktiv (Immer gewährt). Das Aktivieren macht einen Scope nur verfügbar, die anbindende Anwendung muss ihn im Login-Ablauf auch anfragen. Fehlt in der Anfrage openid oder ein erforderlicher Scope, wird die Anmeldung mit dem Fehler invalid_scope abgelehnt. Optionale Scopes werden nur gewährt, wenn die Anwendung sie anfragt und sie auf dem Consent Screen nicht abgelehnt werden.
• Admin-Zustimmung für alle Benutzer erteilen (Admin Consent): Die Zustimmung zu allen Scopes eines Clients kann bereits durch Administratoren im Voraus erteilt werden (nur als Ganzes, nicht je einzelnem Scope) – Benutzer werden dann beim ersten Login bei der Anwendung nicht mehr über den Consent Screen befragt. Ist die Option aktiviert, lassen sich Scopes nur noch als Deaktiviert oder Erforderlich konfigurieren. Scopes, die zuvor auf Optional standen, werden dabei automatisch auf ihren Standardwert zurückgesetzt (profile und email: Erforderlich; phone und relution: Deaktiviert).

Nicht mehr benötigte Clients werden in der Liste Registrierte Clients gelöscht.

Sichtbarkeit je Organisationsebene #

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

• Global: Alle Benutzer im gesamten System können sich anmelden.
• Meta-Organisation: Alle Benutzer der Meta-Organisation sowie ihrer Unterorganisationen können sich anmelden.
• Unterorganisation: Nur Benutzer 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.

Die Scopes liefern folgende Claims:

Erteilte Zustimmungen #

Benutzer sehen in ihrem Profil im Reiter Autorisierte Anwendungen, welchen Anwendungen sie welche Berechtigungen erteilt haben, und können den Zugriff dort widerrufen. Administratoren mit der entsprechenden Berechtigung finden denselben Bereich in den Details eines Benutzers. Beim Widerruf werden auch die bestehenden Autorisierungen der Anwendung für diesen Benutzer entfernt, sodass sich die Anwendung keine neuen Tokens mehr per Refresh-Token holen kann; beim nächsten Login wird die Zustimmung erneut abgefragt.

Protokollierung #

Anmeldungen über den Identity Provider werden sowohl im Audit-Log als auch in der Login-Historie der jeweiligen Benutzer erfasst. In der Login-Historie weist die Spalte IdP-Client aus, über welchen Client die Anmeldung erfolgte.