Überblick

Das OpenID Connect-Protokoll ist eine Erweiterung des OAuth 2.0-Protokolls.
Bei OAuth 2.0 handelt es sich um ein Autorisierungsprotokoll.
Mit OpenID Connect kann zusätzlich die Identität eines Benutzers überprüft werden (Authentifizierung). Der OpenID Connect-Provider dient dabei als zentrale Stelle für die Verwaltung der Benutzerprofile.

Wie die Benutzer am OpenID Connect-Provider identifiziert werden (Benutzername/Kenwort, 2-Faktor-Authentifizierung etc.), ist nicht spezifiziert. An den OpenID Connect-Provider können in der Regel verschiedene Benutzer-Quellen (LDAP, lokale User etc.) angebunden werden. Dies sind die großen Stärken von OpenID Connect, was eine hohe Flexibilität ermöglicht und die Anbindung von bestehenden Benutzerprofilen an DRACOON sehr einfach macht. Insbesondere bedeutet dies, dass keine Benutzerkennwörter oder sonstige Benutzeranmeldedaten an DRACOON übermittelt werden. Es werden lediglich ein Access Token (für die Benutzer-Autorisierung) und ein ID Token (für die Benutzer-Authentifizierung) an DRACOON übergeben.

DRACOON und OpenID Connect

Die DRACOON-Umgebung übernimmt in diesem Fall die Rolle eines OAuth-2.0-Clients, der OpenID Connect benutzt. Sie stellt somit eine Relying Party (RP) dar.

1. Will sich ein Benutzer z.B. per Web App am DRACOON einloggen, wird der Browser an den OpenID Connect-Provider (IdP) weitergeleitet.
2. Der Benutzer wird aufgefordert, sich zu identifizieren (z.B. mit Benutzername und Kennwort).
3. Wenn dies erfolgreich war, wird vom IdP ein Auth Code ausgestellt, und dieser wird über den Browser an die RP (DRACOON) übergeben.
4. Die RP (DRACOON) tauscht diesen Auth Code am IdP gegen einen Access Token und ID Token ein, nachdem sich die RP mit einem Client Secret am IdP authentifiziert hat.
   Der ID Token ist dabei als JSON Web Token (JWT) kodiert, dessen Signatur die RP (DRACOON) am IdP überprüfen kann.
5. Falls die Schritte 1-4 erfolgreich waren, hat sich der Benutzer erfolgreich über OpenID Connect im DRACOON eingeloggt.

Im folgenden Diagramm sind die oben beschriebenen Schritte nochmals grafisch dargestellt:

Zusätzliche Sicherheit durch PKCE

Einige OpenID Connect-Provider (z.B. Keycloak) bieten die Möglichkeit, das Protokoll durch PKCE (Proof Key for Code Exchange) zusätzlich abzusichern. Dabei soll verhindert werden, dass Schadsoftware mithilfe des Auth Codes einen gültigen Access Token und ID Token erlangen kann (vorausgesetzt, Client ID und Client Secret sind dem Angreifer bekannt). Dabei wird im Client beim Authorization Request eine Zufallszahl (Code Verifier) und ein dazugehöriges kryptografisches Rätsel (Challenge) erzeugt, das nur mithilfe des Code Verifiers gelöst werden kann. Die Challenge wird an den OpenID Connect Provider übermittelt. War die Authentifizierung erfolgreich und möchte danach der Client den Auth Code in Access und ID Token umtauschen, muss dieser erst den Code Verifier an den OpenID Connect Provider übermitteln. Der OpenID Connect Provider überprüft, ob dieser Code Verifier die Lösung der Challange ist und kann damit gewährleisten, dass kein „falscher Client“ versucht den Access und ID Token einzuholen.

OpenID Connect in DRACOON konfigurieren

Ein OpenID Connect-Provider wird im DRACOON unter Einstellungen > Authentifizierung > OpenID-Provider hinzufügen konfiguriert.

Dabei müssen die verschiedenen Endpoint-URLs des OpenID Connect-Providers eingetragen werden, mit denen sich die Benutzer authentifizieren können (Authorization Endpoint-URL), die Access Token und ID Token angefordert werden können (Token Endpoint-URL), die User Infos erhalten werden können (UserInfo Endpoint-URL) und die Signatur des id token (JWT) überprüft werden kann (JWKS Endpoint-URL).

Normalerweise möchte man über die (technische) Benutzer-ID hinaus weitere Attribute der Benutzer mithilfe der UserInfo Endpoint URL abfragen, z.B. den Namen oder die E-Mail-Adresse. Unter Nutzung dieses Endpunkts kann der DRACOON die beim OpenID Connect-Provider verfügbaren Attribute zu einem Benutzer – "Claims" genannt – abfragen.
Im einfachsten Fall wird der Scope-Wert des OpenID-Connect-Authentifizierungs-Requests um vordefinierte Werte erweitert, die den Zugriff auf bestimmte Claims anfordern.
Zum Beispiel wird in Scopes neben „openid“ (damit wird eine Authentifizierung mittels OpenID Connect angefordert) auch „email“ oder „profile“ hinterlegt.
Entsprechend sind dann noch die Felder Mapping-Claim und Fallback User Mapping Claim auszufüllen.

OpenID Connect definiert die in der folgenden Tabelle dargestellten Standardwerte:

Zudem müssen die Client ID und das Client Secret hinterlegt werden, damit sich der DRACOON am OpenID Connect-Provider authentifizieren kann.

Wie bereits oben beschrieben, kann für einige OpenID Connect-Provider PKCE (Proof Key for Code Exchange) aktiviert werden. In PKCE Challenge Methode wird angegeben, wie die Challenge erzeugt wird. Momentan gibt es die Möglichkeit, zwischen plain (code_challenge = code_verifier) und S256 (code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))) zu wählen, wobei S256 als "sicher" angenommen werden kann.