OpenIDConnect und OAuth2 mit ADFS – Deep Dive

Die Microsoft Active Directory Federation Services (ADFS) bieten nicht nur die Möglichkeit Single-Sign-On (SSO) für Enterprise Applikationen über SAML einzurichten, sondern unterstützen auch die mittlerweile marktführenden Protokolle OpenIDConnect (OIDC) und OAuth2. Da die Einrichtung einer solchen Applikation wohl nicht zu den alltäglichen Aufgaben eines System Administrators gehören und es auch hier einige Stolpersteine gibt, möchte ich den Vorgang in diesem Beitrag so gut als möglich demystifizieren.

Problemstellung

Problem

Meiner Meinung nach macht es immer Sinn, ein solch komplexes Thema anhand einer konkreten Problemstellung darzustellen. Daher beginnen wir mit einem Szenario, welches wohl jedem Administrator bekannt vorkommen sollte.

Unser fiktives Unternehmen baut auf einem Active Directory als Rückgrat auf. In diesem wurden für alle Mitarbeiter User Accounts erstellt. Damit klappt die Anmeldung bei allen Windows Diensten (Workstation, Fileserver, Exchange, …) schon einmal problemlos. Als Protokoll wird hierbei meist Kerberos oder NTLM verwendet. Diese beiden Protokolle eignen sich innerhalb des internen Unternehmensnetzwerkes sehr gut und bilden nach wie vor die Speerspitze. Heutzutage werden aber viele Applikationen nicht mehr im eigenen Netzwerk betrieben sondern befinden sich in der Cloud. Über das Internet funktioniert Kerberos und NTLM allerdings nicht mehr so gut und daher brauchen wir dafür Alternativen. Genau hier kommt OAuth2 und OIDC ins Spiel.

Nun akquiriert unser Unternehmen eine Third-Party Web Applikation. Wie das heute so üblich ist, wird diese in der Cloud des Anbieters betrieben. Die IT muss nun einem bestimmten Personenkreis innerhalb des Unternehmens die Möglichkeit bieten, sich in der Web Applikation anzumelden. Der „alte“ und umständliche Weg wäre es, jeglichen Mitarbeitern einen weiteren Benutzer in der App anzulegen und die Zugangsdaten den jeweiligen Personen zukommen zu lassen. Welche Probleme ergeben sich daraus? Aus Sicht der IT-Abteilung sogar einige:

• Erhöhter Aufwand – die Benutzer müssen nun an zwei Stellen (dem AD und der Third-Party App) administriert werden. Unternehmen setzen nun aber in der Regel auf eine Vielzahl solcher Applikationen, was den Aufwand immer weiter erhöht. Innerhalb von On- und Offboardings muss dies ebenfalls berücksichtigt werden.
• Die Angriffsfläche verbreitert sich – wieder neue Benutzer-Identitäten, womöglich keine Kontrolle über Password-Policies.
• Kein einheitliches Logging – wer meldet sich wann an der Web Applikation an? Viele Anbieter bieten ein solches erweitertes Logging nicht an. Und wenn doch, wie erstellt man dafür ein einheitliches Alerting?
• Datenleck – die Third-Party App wird gehackt und Passwörter werden geleakt. Wie geht man damit um?

Lösung

Mithilfe der Integration von OAuth oder OIDC können genau wir diese Probleme umlaufen. Anstelle jedem Mitarbeiter einen weiteren Benutzer mit Passwörtern in jeder Applikation manuell anlegen zu müssen, übernimmt die Authentifizierung & Autorisierung unser ADFS. Das Logging wird auf unsere On-Premises Umgebung zentralisiert und jeglicher Login muss den Anforderungen unserer AD-Policies erfüllen. Technisch gesehen hat natürlich trotzdem jeder Mitarbeiter in den Third-Party Apps einen Benutzer, da die Authentifizierung allerdings ausschließlich über das ADFS verläuft, haben sie dort keine Passwörter hinterlegt. Möchte ein Mitarbeiter nun die App verwendet, authentifiziert er sich zuerst am ADFS, bekommt einen Token ausgestellt (dazu später mehr) und gibt diesen Token an die App weiter. Die App gewährt anschließend den Zugriff ohne jemals ein Passwort des Nutzers gesehen zu haben.

Was ist OIDC und OAuth2

OAuth2

Bevor wir direkt mit der Konfiguration auf ADFS Ebene beginnen, sollten wir uns aber zuerst ein wenig über die Theorie von OIDC und OAuth2 unterhalten und welchen Mehrwert eine Authentifizierung dieser dem Nutzer bietet. Die nachfolgende Erklärung ist stark vereinfacht und auf die wichtigsten Informationen zusammengekürzt. Sie sollten dir aber einen grundsätzlichen Überblick über den Einsatz der Protokolle geben.

OAuth2 ist ein Autorisierungsprotokoll, welches es einer Anwendung ermöglicht, den Zugriff auf Ressourcen im Namen eines Benutzers zu beantragen, ohne, dass die Zugangsdaten des Benutzers an die Anwendung weitergegeben werden. Die Authentifizierung übernimmt dabei ausschließlich der sogenannte Identity Provider (kurz IdP) und stellt anschließend einen Validierungstoken für den Zugriff aus.

Ich denke bei vielen Benutzern ist ein solches Szenario bereits im Umfeld eines Google Kontos vertreten (auch andere namenhafte Hersteller bieten einen solchen Dienst an). Als Benutzer erstellt man sich ein Google Konto, hinterlegt dort seine E-Mail Adresse, das Passwort und vielleicht auch noch personenbezogene Daten. Möchte man nun auf eine Drittanbieter-App zugreifen und unterstützt diese App OAuth2 für Google, kann eine nahtlose Anmeldung über den zuvor erstellen Google Account erfolgen, ohne, dass der Nutzer sich erneut authentifizieren oder weitere Daten angeben muss. Das Google Konto dient hierbei als Identity Provider und stellt für die externe Applikationen einen Token mit allen relevanten Informationen aus. Da die externe Applikation dem IdP vertraut (was eine Voraussetzung ist), kann so der Benutzer eindeutig verifiziert werden.

OIDC

OIDC baut auf dem OAuth2 Protokoll auf und erweitert dieses um den Authentifizierungsmechanismus. Sehr vereinfacht dargestellt bietet OIDC zusätzlich die Möglichkeit, weitere benutzerbezogene Informationen (sogenannte Claims) im ausgestellten Token mitzuschicken. Der dabei verwendete ID-Token wird im JWT-Format (JSON) ausgestellt. Es gibt einen fließenden Übergang zwischen OAuth2 und OIDC und als Endanwender merkt man in den meisten Fällen gar nicht, welches Protokoll zwischen IdP und Applikation ausgehandelt wurde.

Unterschiede

Man stelle sich wieder die Third-Party App vor, welche mittlerweile an das On-Premises ADFS angebunden ist. Welche Vorteile würden sich nun ergeben, wenn man auf OAuth2 oder OIDC setzt?

OAuth2 ist ein reines Autorisierungsprotokoll. Das bedeutet, der Nutzer authentifiziert sich am ADFS und das ADFS stellt einen Access Token bereit. Mit diesem Token kann der Nutzer nun zur Third-Party App gehen und verifiziert dadurch seine Identität. Voraussetzung hierbei ist allerdings, dass die Third-Party App den Nutzer bereits kennt. Wurde im Vorfeld für den jeweiligen Nutzer kein Account in der App angelegt, endet hier seine Reise mit einer Fehlermeldung.

Im Unterschied dazu das gleiche Szenario mit OIDC. Wie oben beschrieben, baut OIDC auf OAuth2 auf, der Autorisierungslayer bleibt also erstmal gleich. Zusätzlich wird dem Nutzer jetzt aber auch ein ID-Token ausgestellt. Dieser ID-Token kann unterschiedliche Informationen des Nutzers beinhalten. Vorstellbar sind zum Beispiel der Nutzername, Vor- und Nachname und vielleicht auch die Position innerhalb des Unternehmens. Die Informationen werden Claims benannt und lassen sich im ADFS frei konfigurieren. Der große Vorteil ist jetzt aber, dass die Applikation einen nicht vorhandenen Nutzer ohne Probleme anlegen könnte. Weiters könnte man auch die hinterlegten Informationen eines bestehenden Benutzers aktualisieren. Ändert sich beispielsweise der Nachname des Nutzers, reicht es aus, diesen innerhalb des Active Directory anzupassen. Loggt sich dieser das nächste Mal in der Third-Party Applikation an, kann der Nachname auch automatisch dort anhand des ID-Tokens angepasst werden.

Eine Anmeldeseite einer Applikation, die sowohl die Interne-, als auch SSO-Authentifizierung unterstützt, kann zum Beispiel so aussehen:

Vorteile von SSO über OIDC

Die Konfiguration und Administration einer ADFS Umgebung ist natürlich mit zusätzlichen Kosten verbunden. Daher sollte man sich vorab die Frage stellen, welche Vorteile eine solche SSO-Umgebung überhaupt bieten kann. Dabei liegen diese aber gerade im Enterprise-Umfeld auf der Hand:

• Anstatt einem Mitarbeiter in jeder Applikation eine neue Identität anzulegen, reicht es aus, das Active Directory als primäre Identitätsquelle zu pflegen. Das spart nicht nur Zeit bei der Neuanlage eines Nutzers, sondern reduziert auch den zukünftigen administrativen Aufwand.
• Verlässt ein Mitarbeiter das Unternehmen, reicht es im ersten Schritt aus, das Active Directory Konto zu deaktivieren. Verwendet eine Applikation das ADFS als IdP, wird die Authentifizierung sofort unterbunden und bereits ausgestellte Tokens invalidiert.
• Die Authentifizierung wird zentralisiert, die Richtlinien vereinheitlicht und die Überwachung vereinfacht. Jeder Zugriff wird protokolliert und kann mit verschiedenen Tools automatisiert ausgewertet werden. Das erhöht nicht nur die Nachvollziehbarkeit sondern kann mit dem entsprechenden Tooling Brute-Force-Attacken entgegenwirken.
• Wurden für einen Nutzer im AD spezielle Zugriffsregeln definiert (bspw. der Zugriff darf nur im Zeitraum von 08:00-17:00 Uhr stattfinden), gelten diese nun ebenfalls für externe Applikationen.

Allerdings gibt es durch die Integration von SSO nicht nur Vorteile für den Administrator. Auch den Nutzern wird das Leben erleichtert:

• Der Benutzer muss sich nur noch einen Satz an Credentials merken und ein Passwortwechsel im Active-Directory reicht aus, um ein geleaktes Kennwort vollständig zu egalisieren.
• Es reicht aus, sich einmalig am ADFS zu authentifizieren. Solange man die Browser Session beibehält werden alle externen Applikationen automatisch im Kontext des Benutzers angemeldet (Stichwort SSO).
• Heutzutage werden viele Enterprise Applikationen mit einem zweiten Faktor abgesichert. Somit hat ein Nutzer relativ schnell unzählige TOTP Tokens in der eigenen Authenticator App am Smartphone. Zentralisiert man die Anmeldung dieser Applikationen am ADFS, reicht ein TOTP Token für das ADFS aus um alle Third-Party Apps abzudecken.

OIDC, OAuth2 und SAML für ADFS

Glücklicherweise unterstützt ADFS die gängigsten Authentifizierungs- und Autorisierungsprotokolle SAML, OAuth2 und OIDC. Somit sollte sich jede Applikation, die zumindest eines der zuvor genannten Protokolle unterstützt, relativ problemlos in den Authentifizierungsflow einbinden lassen. Wer anstelle der On-Premises Umgebung auf O365 und Azure AD setzt, kann auf Azure AD Enterprise Applikationen zurückgreifen. Es bietet die gleichen Schnittstellen und technisch gesehen werkelt dort auch nur eine modifizierte und hochverfügbare ADFS Umgebung – aber das nur als Notiz am Rande.

Auch wenn sich die Integration von SAML und OIDC innerhalb ADFS unterscheiden, ist der Authentifizierungsflow bei allen gleich aufgebaut:

Grafik von https://www.onelogin.com/

Vereinfacht dargestellt passieren folgende Schritte:

1. Der Benutzer öffnet eine Applikation (bspw. eine Webanwendung) und möchte sich dort authentifizieren. Anhand der eingetragenen E-Mail Adresse leitet die Applikation den Nutzer zum IdP weiter. In unserem Fall an die ADFS Instanz.
2. Innerhalb der ADFS Umgebung authentifiziert sich der Nutzer mit den durch den Administrator konfigurierten Merkmalen. Seitens ADFS könnte das eine einfache Anmeldung mit Benutzername & Passwort sein. Genauso werden aber MFA (Multi-Faktor-Authentifizierung), zertifikatsbasierte- und passwordless-Anmeldungen unterstützt.
3. Hat der Nutzer sich erfolgreich authentifiziert, stellt der IdP einige Token aus (mehr dazu später). Mit diesen Tokens wechselt der Browser wieder zur ursprünglichen Applikation und übergibt sie dieser.
4. Die Applikation verifiziert die ausgestellten Token und gibt den Zugang frei. Der Nutzer gilt somit als authentifiziert und darf die Applikation verwenden.

Analyse des ausgestellten Tokens

Meldet sich ein Nutzer für eine Applikation am ADFS an, werden folgende Tokens ausgestellt:

Im Sinne der OIDC Implementierung ist der ID Token für uns der wichtigste und interessanteste Token. Daher schauen wir uns diesen nachfolgend etwas genauer an. Wie in der Tabelle ersichtlich, beinhaltet der ID Token die vom ADFS mitgeschickten Claims – also jene Informationen, die ADFS zusätzlich über den Nutzer preisgibt. Das kann grundsätzliches jedes beliebige AD-Attribut sein aber in vielen Fällen werden folgende Daten

• Vor- Nachname
• E-Mail Adresse
• EmployeeID
• Gruppenmitgliedschaften

Der Token ist Base64 codiert und immer gleich aufgebaut: Header, Payload (Data), Signature. Wird der Token decodiert bekommt man ein JSON nach folgendem Schema:

{
  "aud": "6ae19765-6bce-47fe-ab39-fea801fba272",
  "iss": "https://auth.schweigerstechblog.de/adfs",
  "iat": 1697447965,
  "nbf": 1697447965,
  "exp": 1697451565,
  "auth_time": 1697447577,
  "sub": "K9aaS9eMkJiUcrEoaTbXZR90U99U7HlxSKa5CQ2s7oc=",
  "upn": "kschweiger@schweigerstechblog.de",
  "unique_name": "SWT\kschweiger",
  "pwd_url": "https://auth.schweigerstechblog.de/adfs/portal/updatepassword/",
  "sid": "S-1-5-21-988405549-3412143714-2819284977-3374",
  "EmployeeID": "01",
  "Department": "Blogging",
  "apptype": "Confidential",
  "appid": "6ae19765-6bce-47fe-ab39-fea801fba272",
  "authmethod": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
  "ver": "1.0",
  "scp": "openid"
}

Der Großteil der oben aufgeführten Eigenschaften werden standardmäßig mitgeschickt und dienen zur Verifikation des IdPs und dessen Endpunkte. Allerdings befinden sich darin ebenfalls die am ADFS konfigurierten Claims – wie in diesem Fall die „EmployeeID“ und das „Department“. Da das ADFS als Datenquelle das Active Directory verwendet, können daraus alle beliebigen Attribute als Claim mitgeschickt werden. Werden bei der Nutzeranlage demnach die Attribute eines Benutzers sauber befüllt, können diese Informationen problemlos an eine Applikation via OIDC (oder auch SAML) weitergereicht werden.

Applikationsintegration

Hierbei muss aber noch gesagt sein, dass nicht jede Applikation alle Funktionen von OIDC unterstützt. So bieten manche Hersteller reinen OAuth-Support an und die Nutzer müssen weiterhin manuell über die Weboberfläche der App administriert werden. Andere Hersteller wiederum haben den gesamten OIDC-Stack implementiert. Das bedeutet, dass Benutzer durch Self-Provisioning automatisch in der App anhand der mitgeschickten Claims angelegt werden. Welche Funktionen also genau zur Verfügung stehen, müssen pro Applikation einzeln evaluiert werden. Glücklicherweise ist die Integration von OAuth2, OIDC oder SAML mittlerweile sehr stark verbreitet und so ziemlich jede Enterprise Applikation unterstützt zumindest eines der standardisierten Protokolle.

Um den Rahmen dieses Artikels nicht zu sprengen, schauen wir uns im nächsten Beitrag die Konfiguration einer solchen Applikation innerhalb einer ADFS Umgebung an.