Neue OAuth2/OIDC Application in ADFS anlegen

Wie erstellt man eigentlich einen OAuth2/OIDC SSO-Endpunkt im ADFS? Welche Parameter sind wichtig und wie werden sie gesetzt? Diesen Fragen möchte ich in diesem Beitrag auf den Grund gehen und daher schauen wir uns gemeinsam an, wie man eine sogenannte „Application Group“ im ADFS konfiguriert. Wer noch nicht weiß, was OAuth2/OIDC überhaupt ist und welche Vorteile die Integration dieser in einer Enterprise Umgebung bringen, sollte zuerst folgenden Artikel durchstöbern.

ADFS Management Konsole

Schauen wir uns die ADFS Management Konsole dafür einmal oberflächlich an. Sie basiert, wie viele Microsoft Verwaltungsschnittstellen, auf der MMC (Microsoft Management Console) und bietet eine grafische Benutzeroberfläche. Für Administratoren, die lieber mit der PowerShell arbeiten, hat Microsoft alle nötigen Funktionen ebenfalls als CMDLET abgebildet.

In der ADFS MMC lassen sich neben der grundlegenden Konfiguration der ADFS Farm, der veröffentlichten Endpunkte und der Zugriffsrichtlinien, auch die angebundenen Applikationen verwalten.

Ähnlich wie die SAML Applikationen über den Reiter „Relying Party Trusts“ verwaltet werden, so werden die über OIDC/OAuth2 angebundenen Apps über den Menüpunkt „Application Groups“ administriert.

OIDC/OAuth2 Applikation anbinden

Application Templates

Über den Application Group Wizard können wir Schritt für Schritt die Konfiguration einer neuen OIDC/OAuth2 Applikation vornehmen. Dabei stehen uns unterschiedliche Templates zur Verfügung:

• Native Application
• Server Application
• Web Browser

Die Benennung und Verwendung der Templates kann gerade am Anfang etwas irreführend sein. Umreisen wir daher die wichtigsten Unterschiede kurz:

In der Welt von OAuth2 und OIDC unterscheidet man Applikationen in zwei Bereiche: vertrauenswürdig (confidential) oder öffentlich (public). Confidential Applikationen besitzen ein Secret, welches nur dem IdP (in unserem Fall ADFS) und der Applikation bekannt ist. Dieses Secret wird im Backend der Applikation gespeichert und dient zur Authentifizierung gegenüber dem IdP. Bei einer nativen Applikation hingegen, welche beispielsweise auf dem Endgerät des Nutzers ausgeführt wird, ist der Austausch eines solchen Secrets nicht auf sicherem Wege möglich und wird daher weggelassen.

Eine Server Applikation wird, wie es der Name bereits vermuten lässt, zentral auf einem Server betrieben. Clients und Benutzer greifen über einen Web-Browser darauf zu und verwenden die Funktionen, die die Applikation bereitstellt. Da die Anwendung zentral betrieben wird und Nutzer keinen direkten Zugriff auf den dahinterliegenden Code haben, können zwischen IdP und Applikation ein Secret ausgehandelt werden. Dieses Secret dient zur eindeutigen Identifikation der Anwendung.

Möchte man also wie in unserem Beispiel eine Web Applikation anbinden, ist das Template „Server Application accessing Web API“ die richtige Wahl. Tatsächlich verwendet man hauptsächlich dieses Template und die native App ist eher eine Randerscheinung und wird meist von Entwicklern verwendet.

Redirect URL

Der nächste wichtige Punkt bildet die „Redirect URL“. Um die Notwendigkeit einer solchen URL zu verstehen, müssen wir uns noch einmal die Funktionsweise von OAuth2/OIDC anschauen.

Der Benutzer möchte sich in der jeweiligen Applikation authentifizieren und wird an den hinterlegten IdP weitergeleitet. In unserem Fall wird dabei das ADFS Frontend aufgerufen. Der Nutzer gibt seine Active Directory Credentials ein und erwartet sich, anschließend die Applikation verwenden zu können. Damit das funktioniert, muss ADFS wissen, an welche URL der Nutzer nach der erfolgten Authentifizierung weitergeleitet werden muss. Und genau diese URL ist die hier genannte „Redirect URL“.

Die „Redirect URL“ wird dabei von der Applikation, bzw. dessen Hersteller selbst vorgegeben und kann nicht frei gewählt werden.

Client Secret

Wie im Application Templates Kapitel erläutert, handelt es sich hierbei um eine Confidential Server Applikation. Daher muss zwischen Applikation und IdP ein Secret ausgehandelt werden. Dieses Secret kann sowohl asymmetrisch (Public/Private Key) als auch symmetrisch sein. In den meisten Fällen verwendet man dafür einen symmetrischen Key. Das kann sich aber von Applikation zu Applikation unterscheiden und muss in der Doku des Herstellers nachgeschlagen werden.

Wie es mit Passwörtern so üblich ist, darf auch dieses Secret nicht an die Öffentlichkeit gelangen. Im Best-Case Szenario ist es ausschließlich dem IdP und der Applikation bekannt.

Damit haben wir nun bereits alle notwendigen Schritte unternommen, um die Server Applikation zu konfigurieren und einzubinden. Nun muss noch festgelegt werden, welche Nutzer in welcher Form auf die Applikation zugreifen dürfen. Diese Rolle übernimmt dabei die Web API.

Web API

Ähnlich, wie sich eine Server Applikation über die Redirect URL identifizieren lässt, geschieht das zwischen Server Applikation und Web API über den Identifier der Server Applikation. Daher hinterlegen wir den „Client Identifier“ (siehe Kapitel Redirect URL) der Server Applikation für die Web API.

Damit haben wir eine Zuordnung zwischen der zuvor erstellen Server Applikation und der Web API geschaffen.

Access Control Policy

Die Zugriffsrichtlinien bestimmen, welche Benutzer unter welchen Bedingungen Zugriff auf die dahinterliegende Applikation bekommen können. ADFS bietet dabei eine breite Palette an Einstellungsmöglichkeiten:

• Bestimmte Active Directory Gruppen
• Von innerhalb des Unternehmensnetzwerkes (Intranet) oder auch aus dem Internet
• MFA für bestimmte Benutzergruppen erzwingen

ADFS bringt dabei bereits einige vordefinierte Richtlinien mit. Genauso können allerdings auch eigene Richtlinien nach den eigenen Vorgaben erstellt werden.

Application Permissions

Der letzte Menüpunkt entscheidet darüber, welche Berechtigungen die Applikation besitzt und welche Scopes angefragt werden dürfen.

In der Regel reichen zwei Scopes aus:

• OpenID: Damit wird OAuth2 um das OIDC Protokoll erweitert und neben einer Autorisierung ist nun auch eine Authentifizierung möglich.
• Allcatclaims: Die Claims werden direkt im OIDC Identity Token mitgeschickt und können von der Applikation im JWT (JSON Web Token) extrahiert werden (siehe nächstes Kapitel).

Die restlichen Scopes werden kaum verwendet und kommen nur sehr vereinzelt zur Anwendung.

Claims

Für manche Applikationen mag es notwendig sein, bestimmte „Claims“ mitzuschicken. Claims sind dabei grundsätzlich nichts anderes, als Attribute aus dem Active Directory des jeweiligen Nutzers. So können beispielsweise der Vor- und Nachname oder verschiedene Gruppenmitgliedschafen des Nutzers als Claim an die Applikation übergeben werden. Aufgrund des großen Umfangs dieses Kapitels, besprechen wir das Thema in einem zukünftigen Beitrag.

Somit haben wir unsere OAuth2/OIDC Applikation im ADFS erfolgreich angelegt. Das ist aber noch nicht das Ende der Reise. Denn auch die Applikation muss konfiguriert und ans ADFS angebunden werden.

Da sich die Konfiguration von Applikation zu Applikation unterscheidet, gehen wir den Prozess in diesem Beitrag exemplarisch durch.

Web Applikation konfigurieren

Genauso wie unser ADFS eine „Redirect URL“ benötigt um den User nach erfolgter Authentifizierung zurück zur Applikation zu schicken, benötigt die Applikation eine URL, um den User überhaupt einmal zum ADFS weiterzuleiten. Diese URL heißt „Authorization Endpoint“ und schaut standardmäßig wie folgt aus: „https://auth.schweigerstechblog.de/adfs/oauth2/authorize/“ (Domain muss durch eure Domain ersetzt werden).

ADFS stellt für OIDC allerdings auch noch weitere Endpunkte zur Verfügung, welche sich alle über die URL „https://auth.schweigerstechblog.de/adfs/.well-known/openid-configuration“ auslesen lassen. Welche Endpunkte benötigt werden, hängt dabei maßgeblich von der jeweiligen Applikation ab und kann von Fall zu Fall unterschiedlich sein. Den „Authorization Endpoint“ wird man allerdings in jedem Fall benötigen.

Weiters benötigt die Applikation den zuvor gesetzten „Client Identifier“, sowie das generierte „Secret“.

Wie bereits geschrieben hängt die Art und Weise, welche Informationen die Applikation vom IdP benötigt, stark von der Implementierung der OAuth2/OIDC Schnittstelle ab. In folgendem Beispiel seht ihr die notwendigen Parameter für die Aktivierung von SSO für die ANEXIA Engine:

Das war’s auch schon. Neben Claims gibt es allerdings noch andere Konfigurationsmöglichkeiten, diese auszuführen würde aber den Rahmen des Artikels sprengen. Wenn ihr euch für weitere Themen im Bereich ADFS interessiert, schaut euch auch gerne die folgenden Beiträge näher an.