Konfigurieren des User Provisionings und der Authentifizierung über OICD

Über Single Sign-On (SSO)

Single Sign-On (SSO) ermöglicht es Nutzern, sich einmal zu authentifizieren und nahtlos auf mehrere Anwendungen und Dienste zuzugreifen, ohne sich wiederholt anmelden zu müssen. Die SSO-Integration kann über verschiedene Protokolle erfolgen, wobei SAML2 (Security Assertion Markup Language 2.0) und OIDC (OpenID Connect) die am häufigsten verwendeten sind. Diese Protokolle ermöglichen eine sichere und standardisierte Authentifizierung zwischen OpenID Provider (OP) und einer Relying Party (RP).

Die Integration von SSO über SAML2 oder OIDC erfordert eine sorgfältige Abstimmung zwischen dem OP und dem RP. Beide Protokolle bieten hohe Sicherheit und Flexibilität, unterscheiden sich jedoch in ihrer Implementierung. SAML2 stützt sich auf XML-basierte Nachrichten, während OIDC auf dem modernen OAuth2-Framework basiert und JSON-Web-Token (JWT) verwendet. Die Wahl des Protokolls hängt von den spezifischen Anforderungen des Anwendungsfalls und der vorhandenen Infrastruktur des Systems ab.

Einführung

Dieser Artikel beschreibt die Single Sign-On (SSO) Authentifizierungsmethode über OpenID Connect (OIDC) für die imc Learning Suite und gibt einen Überblick über die notwendigen Konfigurationsschritte.

OIDC wurde als Single Sign-On-Lösung für die imc Learning Suite implementiert. Das Learning Management System (LMS) verfügt über eine Initiierungsseite (Anfrageseite), die den OIDC-Authentifizierungsprozess anhand vorkonfigurierter Parameter auslöst.

Der allgemeine Workflow für die Implementierung umfasst die folgenden Schritte:

Button / Link oder Einstiegspunkt zur imc Learning Suite
SSO Initiierungsseite
Umleitung zum Autorisierungsserver (OP) / Remote-Nutzeranmeldung
Autorisierungsserver sendet den angemeldeten Nutzer zurück an die SSO-Antwortseite des LMS
Authentifizierung

Für den Fall, dass ein Nutzer nicht in der LMS-Datenbank gefunden werden kann, kann Account Provisioning so konfiguriert werden, dass nahtlos ein LMS-Nutzer für die authentifizierte Person erstellt wird. Zusammen mit dieser Account Provisioning-Funktion können die persönlichen Daten in der LMS-Datenbank bei jeder Nutzeranmeldung auf Wunsch synchronisiert werden.

Über OpenID Connect (OIDC)

OpenID Connect baut auf dem OAuth 2.0-Framework auf und fügt einen Identitätslayer hinzu, der die Bereitstellung von Benutzerinformationen und die Einrichtung von Anmeldesitzungen ermöglicht. Während OAuth 2.0 darauf ausgelegt ist, den Zugriff auf Anwendungen von Drittanbietern zu delegieren, ohne die Identität des Benutzers preiszugeben, ermöglicht OpenID Connect sowohl die Benutzerauthentifizierung als auch die Autorisierung in einem einzigen Ablauf, indem ein ID-Token und ein Zugriffstoken für den Zugriff auf geschützte Ressourcen bereitgestellt werden.

OIDC-Flow

Das OpenID Connect-Protokoll folgt einer strukturierten Abfolge von Ereignissen, die im Folgenden beschrieben werden:

Der Client / Mandant (Relying Party oder RP) initiiert eine Anfrage an den OpenID Provider (OP).
Der OP authentifiziert den Endnutzer, der daraufhin eine Autorisierung erhält.
Der OP stellt ein ID-Token und in den meisten Fällen auch ein Access-Token aus.
Der RP kann dann das Access Token verwenden, um eine Anfrage an den UserInfo-Endpoint zu stellen.
Der UserInfo-Endpunkt gibt die relevanten Informationen zu dem authentifizierten Endnutzer zurück.

Diese Abfolge ist in der folgenden Abbildung dargestellt:

Claims

In OpenID Connect sind Claims Name/Wert-Paare mit Informationen über einen authentifizierten Nutzer, die im ID-Token enthalten sind. Diese Claims enthalten Details über den Nutzer, wie z. B.:

Member	Beschreibung
sub	Subject - Kennung für den Endnutzer beim Aussteller
preferred_username	Kurzname, mit dem der Endnutzer bei der Relying Party (RP) angesprochen werden möchte
profile	URL der Profilseite des Endnutzers. Der Inhalt dieser Webseite SOLLTE sich auf den Endnutzer beziehen.
email	Bevorzugte E-Mail-Adresse des Endnutzers

Antwort-Typ

In der OIDC-Konfiguration gibt der Antwort-Typ die Art der Antwort an, die der Mandant nach dem Authentifizierungsprozess vom Autorisierungsserver erwartet. Er definiert die Token oder Autorisierungscodes, die der Mandant als Teil der Antwort erhält. Übliche Antwort-Typen sind:

Antwort-Typ	Beschreibung
code	Dieser fordert einen Autorisierungscode an, den der Client in der Token-Anfrage gegen ein Zugangs-Token und ein ID-Token austauscht.
id_token	Dieser fordert nur das ID-Token an, das Informationen über den authentifizierten Nutzer enthält.
code id_token & code token	Eine Kombination dieser beiden Typen, die in der Regel verwendet wird, um hybride Datenströme für mehr Flexibilität und Sicherheit zu ermöglichen.

Welcher Antwort-Typ gewählt wird, hängt von dem jeweiligen Datenfluss und den Sicherheitsanforderungen des Mandanten ab.

Scope

Der Scope definiert die Berechtigungen oder Ressourcen, die der Mandant vom Autorisierungsserver anfordert. Der Scope-Parameter ist in der Authentifizierungsanfrage enthalten und kann Standardwerte enthalten wie z. B.:

SCOPE	Beschreibung
openid	obligatorischer Scope für alle OIDC-Anfragen, der angibt, dass der Mandant eine Authentifizierung anfordert
profile	fordert Zugriff auf die grundlegenden Profilinformationen des Endnutzers an (z. B. Name, Profilbild)
email	fordert Zugriff auf die E-Mail-Adresse des Endnutzers an

Antwort-Modus

Der Antwort-Modus legt fest, wie der Autorisierungsserver die Authentifizierungsantwort an den Mandanten zurückgibt. Er gibt die Methode an, mit der die Antwortparameter (wie Token oder Autorisierungscodes) übertragen werden. Übliche Antwort-Modi sind:

SCOPE	Beschreibung
query	Die Antwort wird als Abfrageparameter in der URL zurückgegeben.
form_post	Die Antwort wird als Formulardaten in einer HTTP-POST-Anfrage gesendet, die in der Regel für eine sicherere Handhabung von sensiblen Daten verwendet wird.

Die Wahl des Antwort-Modus hängt von den Anforderungen des Kunden und den Sicherheitsvorgaben für die Kommunikationsmethode ab.

Discovery URL

Die Discovery URL ist ein standardisierter Endpunkt, der es Mandanten ermöglicht, dynamisch Konfigurationsinformationen über den OpenID Provider (OP) abzurufen. Die Discovery URL folgt einem klar definierten Format und endet oft mit „/.well-known/openid-configuration“. Diese URL liefert typischerweise wichtige Metadatenwerte, die es Mandanten ermöglichen, mit dem OpenID Provider (OP) zu interagieren. Diese Werte beinhalten:

Metadatenwerte	Beschreibung
issuer endpoint	Die URL, die den OpenID-Provider eindeutig identifiziert. Sie wird von Mandanten verwendet, um zu verifizieren, dass die Token von einem vertrauenswürdigen Provider ausgestellt wurden.
authorization endpoint	Die URL, an die der Mandant den Endbenutzer weiterleitet, um sich zu authentifizieren und ihm die Berechtigung zum Zugriff auf geschützte Ressourcen zu erteilen.
token endpoint	Die URL, die vom Mandanten verwendet wird, um einen Autorisierungscode gegen ein Zugriffstoken und ein ID-Token auszutauschen oder um Token zu aktualisieren.
userinfo endpoint	Die URL, unter der der Mandant Claims über den authentifizierten Endnutzer abrufen kann, in der Regel nach Erhalt eines Zugriffstokens.
jwks uri	Die URL, unter der die öffentlichen Schlüssel des OpenID-Providers gespeichert sind. Diese Schlüssel werden vom Mandant verwendet, um die Integrität und Authentizität der vom Provider erhaltenen ID-Tokens zu überprüfen.

Client Application

Um eine sichere Verbindung zwischen dem OpenID-Provider (OP) und der Relying Party (RP) herzustellen, stellt der OP der RP die notwendigen Anmeldeinformationen für eine sichere Kommunikation zur Verfügung. Im Folgenden werden die Eigenschaften für die “Client application” beschrieben:

Eigenschaft	Wert	Beschreibung
Client ID	XXXX-XXXXX-XXXXX-XXXXX	ein eindeutiger Identifikator für den RP innerhalb des OPs
Client secret	XXXX-XXXXX-XXXXX-XXXXX	ein geheimer Schlüssel, der von der RP verwendet wird, um sich gegenüber dem OP zu authentifizieren
Redirect URL	https://{{base_url}}/idm/oidc/login https://{{base_url}}/idm/logoff	die URL, an die der OP das ID-Token und die Authentifizierungsergebnisse sendet

Der RP muss dem OP die Redirect-URL mitteilen, an die der OP dann das ID-Token und das Authentifizierungsergebnis sendet.

User Provisioning

Das User Provisioning in OIDC bezieht sich auf den Prozess der Erstellung oder Aktualisierung von Nutzerkonten innerhalb des LMS auf der Grundlage der Identitätsinformationen des authentifizierten Nutzers.

Sobald sich ein Benutzer erfolgreich über OIDC authentifiziert hat, prüft das System, ob ein Konto vorhanden ist. Wird kein Konto gefunden, wird ein neues Nutzerkonto unter Verwendung des eindeutigen Identifikators des Nutzers erstellt, der in der Regel vom OP bereitgestellt wird.

Wenn ein Konto bereits existiert, aktualisiert das System das Konto mit allen neuen oder geänderten Informationen. Durch dieses automatische Provisioning wird sichergestellt, dass die Nutzer je nach ihrem Authentifizierungsstatus den entsprechenden Zugriff und die entsprechenden Berechtigungen erhalten.

Nutzerprofil-Attribute

Es können mehrere Nutzerattribute aus OIDC allen Nutzerprofilen zugeordnet werden, die bereitgestellt werden. Im Folgenden sind die am häufigsten verwendeten Attribute aufgeführt:

Vom OP	LMS Attribut-ID	Beschreibung
Login	LOGIN	Der eindeutige Benutzername oder Identifikator, mit dem sich der Nutzer beim System anmeldet. Er wird in der Regel vom Identitätsprovider (IdP) bereitgestellt und muss systemweit eindeutig sein.
first_name	FIRSTNAME	Vorname des Nutzers
last_name	LASTNAME	Nachname des Nutzers
user_email	EMAIL	die mit dem Nutzerkonto verbundene E-Mail-Adresse
Membership Status	MEMBERSHIP_STATUS	gibt den Status der aktiven Mitgliedschaft des Nutzers innerhalb des Systems oder der Organisation an

Auswirkungen auf andere Komponenten

Es sind keine Auswirkungen auf andere Komponenten zu erwarten. Allerdings sollte auf die Datenqualität der bereitzustellenden Nutzer geachtet werden. Wenn das User Provisioning nicht die einzige Art und Weise ist, wie Nutzer im LMS bereitgestellt werden (z. B. wenn Nutzer manuell oder über eine CSV-Datei erstellt werden), sollten Sie eine eindeutige ID in Betracht ziehen und verwenden, die über alle Quellen hinweg wirklich eindeutig ist. Dies dient dazu, die Duplizierung von Nutzern im LMS zu vermeiden.

Konfiguration von OIDC in der imc Learning Suite

Befolgen Sie die nachfolgend aufgeführten Schritte zur Einrichtung der OIDC-Authentifizierung in Ihrem LMS:

Melden Sie sich bei Ihrem LMS an (imc Learning Suite).
Suchen Sie den Manager „Konfiguration“ und navigieren Sie zu diesem.
Geben Sie in das Feld „Suchbegriff“ den Begriff „OpenID“ ein.
Wählen Sie die Option „🖊️“ (Bearbeiten) und wählen Sie aus dem Dropdown-Menü die Umgebung aus, für die Sie OIDC konfigurieren möchten.
Richten Sie auf der Seite „ OpenID Konfiguration“ die Konfigurationen ein, wie im nachfolgenden Screenshot gezeigt.
Hinweis: Wählen Sie im Abschnitt „OIDC-Profil-Identifikator Attribut“ ein eindeutiges Attribut (z. B. E-Mail, LOGIN) aus dem Dropdown-Menü.
Navigieren Sie zum Tab „Identity provider“ auf der gleichen Seite „OpenID Konfiguration“.
Klicken Sie auf die Option „📄“ in der Seitenleiste, um eine neue Instanz zu erstellen.
Konfigurieren Sie die Identity Providers-Einstellungen gemäß den Angaben in den vorherigen Abschnitten dieses Dokuments („Discovery URL“). Zur Veranschaulichung wird nachfolgend ein Screenshot gezeigt.
Hinweis: Vergewissern Sie sich, dass die „Provider ID“ ein eindeutiger Identifikator ist, der auch im Abschnitt „Client application“ referenziert werden muss.
Zur weiteren Veranschaulichung zeigt die folgende Abbildung, wie verschiedene Elemente der Discovery URL JSON Response auf der OpenID-Konfigurationsseite zugeordnet werden.
Navigieren Sie zum Tab „Client application“ auf der gleichen Seite „OpenID Konfiguration“.
Klicken Sie auf die Option „📄“ in der Seitenleiste, um eine neue Instanz zu erstellen.
Konfigurieren Sie die Einstellungen der “Client application” gemäß den Angaben in den vorherigen Abschnitten dieses Artikels (“Client application”). Der nachfolgende Screenshot dient zur Veranschaulichung.
Hinweis: Vergewissern Sie sich, dass die „Provider ID“ ein eindeutiger Identifikator ist, der auch im Abschnitt “Identity provider” referenziert werden muss.
Navigieren Sie nun zum nächsten Tab „Client-Zuordnung“ und erstellen Sie eine neue Instanz, indem Sie auf die Option „📄“ in der Seitenleiste klicken.
Wählen Sie den Mandanten, für den Sie OIDC konfigurieren möchten, aus dem entsprechenden Dropdown-Menü aus.
Geben Sie den Personenidentifier (z. B. E-Mail) ein, der das eindeutige Attribut für die “Client Zuordnung” ist.
Aktivieren Sie die Checkboxen “Bestehende Benutzer aktualisieren” und “Import ohne Selbstregistrierung” nur, wenn Sie neben dem Single Sign-on auch das User Provisioning aktivieren möchten.
Navigieren Sie nun zum Tab „Mapping-Einträge“ auf dieser Seite und erstellen Sie neue Instanzen für alle Benutzerattribute, die Sie zuordnen möchten, indem Sie auf die Option „📄“ in der Seitenleiste klicken. Siehe den nachfolgenden Screenshot als Referenz.
Hinweis: Das „Quellenfeld“ bezieht sich auf das vom OpenID Provider (OP) übermittelte Attribut, während das „Zielfeld“ das entsprechende Feld im LMS (imc Learning Suite) ist, in dem diese Daten gespeichert sind.
Speichern und schließen Sie die Seite „OpenID Konfiguration“.
Suchen Sie dann die Seite „ Mandanten“ und navigieren Sie zu ihr.
Wählen Sie den Mandanten aus, für den Sie die OIDC-Authentifizierung konfigurieren möchten, wählen Sie die Option „🖊️“ (Bearbeiten) und wählen Sie aus dem Dropdown-Menü die Umgebung aus, für die Sie OIDC konfiguriert haben.
Navigieren Sie nun zum Tab „Zugriff und Sicherheit“.
Markieren Sie die Checkbox “OpenID Connect”, um die OIDC-Authentifizierung zu aktivieren.

Wenn Sie diese Schritte ausführen, wird die OIDC-Authentifizierung erfolgreich in die imc Learning Suite integriert, so dass ein sicheres und nahtloses Anmeldeerlebnis für die Nutzer gewährleistet ist.

Wenn Sie mehrere OpenID-Provider (OPs) für verschiedene Mandanten einrichten, definieren Sie separate OIDC-Einstellungen für jeden Mandanten.