AD FS OpenID Connect/OAuth: Konzepte
Gilt für Active Directory-Verbunddienste (AD FS) 2016 und höher
Moderne Authentifizierungsakteure
Akteur | BESCHREIBUNG |
---|---|
Endbenutzer | Der Sicherheitsprinzipal (Benutzer*in, Anwendungen, Dienste und Gruppen), der auf die Ressource zugreifen muss. |
Client | Ihre Webanwendung, die durch die Client-ID identifiziert wird. Der Client ist normalerweise die Partei, mit der der*die Endbenutzer*in interagiert, und er fordert die Token vom Autorisierungsserver an. |
Autorisierungsserver/Identitätsanbieter (IdP) | Ihr AD FS-Server. Er ist für die Überprüfung der Identität von Sicherheitsprinzipalen verantwortlich, die im Verzeichnis einer Organisation vorhanden sind. Bei erfolgreicher Authentifizierung dieser Sicherheitsprinzipale gibt er Sicherheitstoken aus (Bearerzugriffstoken, ID-Token, Aktualisierungstoken). |
Ressourcenserver/Ressourcenanbieter/Vertrauende Seite | Der Ort, an dem sich die Ressourcen oder die Daten befinden. Er vertraut dem Autorisierungsserver, dass der Client sicher authentifiziert und autorisiert wird, und verwendet Bearerzugriffstoken, um sicherzustellen, dass der Zugriff auf eine Ressource gewährt werden kann. |
Das folgende Diagramm zeigt die grundlegendste Beziehung zwischen den Akteuren:
Anwendungstypen
Anwendungstyp | BESCHREIBUNG | Role |
---|---|---|
Native Anwendung | Manchmal als öffentlicher Client bezeichnet. Dies soll eine Client-App sein, die auf einem PC oder Gerät ausgeführt wird und mit der der Benutzer bzw. die Benutzerin interagiert. | Fordert Token vom Autorisierungsserver (AD FS) für den Benutzerzugriff auf Ressourcen an. Sendet HTTP-Anforderungen an geschützte Ressourcen, wobei die Token als HTTP-Header verwendet werden. |
Serveranwendung (Web-App) | Eine Webanwendung, die auf einem Server ausgeführt wird und für Benutzer über einen Browser zugänglich ist. Da sie in der Lage ist, ihren eigenen geheimen Clientschlüssel oder eigene Anmeldeinformationen zu verwalten, wird sie manchmal als vertraulicher Client bezeichnet. | Fordert Token vom Autorisierungsserver (AD FS) für den Benutzerzugriff auf Ressourcen an. Vor dem Anfordern eines Tokens muss sich der Client (die Web-App) unter Verwendung seines Geheimnisses authentifizieren. |
Web-API | Die Endressource, auf die der*die Benutzer*in zugreift. Stellen Sie sich diese als die neue Darstellung der vertrauenden Parteien vor. | Nutzt Bearerzugriffstoken, die von den Clients abgerufen wurden. |
Anwendungsgruppe
Sie müssen jedem nativen OAuth-Client oder Web-App-OAuth-Client bzw. jeder Web-API-Ressource, der bzw. die mit AD FS konfiguriert ist, eine Anwendungsgruppe zuweisen. Konfigurieren Sie die Clients in einer Anwendungsgruppe für den Zugriff auf die Ressourcen in derselben Gruppe. Eine Anwendungsgruppe kann mehrere Clients und Ressourcen enthalten.
Sicherheitstoken
Die moderne Authentifizierung verwendet die folgenden Tokentypen:
- id_token: Ein JWT-Token, das vom Autorisierungsserver (AD FS) ausgestellt und vom Client genutzt wird. Ansprüche im ID-Token enthalten Informationen über den*die Benutzer*in, sodass der Client diese verwenden kann.
- access_token: Ein JWT-Token, das vom Autorisierungsserver (AD FS) ausgestellt wird und von der Ressource genutzt werden soll. Der Anspruch „aud“ oder „audience“ dieses Tokens muss mit dem Bezeichner der Ressource oder Web-API übereinstimmen.
- refresh_token: Wird von AD FS für den Client ausgegeben, damit dieser es verwenden kann, wenn er das „id_token“ und „access_token“ aktualisieren muss. Das Token ist für den Client undurchsichtig und wird nur von AD FS genutzt.
Lebensdauern von Aktualisierungstoken
- Einfache Anmeldung, ohne KMSI, Gerät nicht registriert: AD FS wendet
SsoLifetime
undDeviceUsageWindowInDays
an. Für das erste Aktualisierungstoken giltlifetime=DeviceUsageWindowInDays
oderSsoLifetime
, basierend darauf, welches Feld niedriger ist. Es werden jedoch keine weiteren Aktualisierungstoken ausgegeben. - KMSI-Anmeldung,
EnableKmsi=true
in AD FS-Konfiguration undkmsi=true
als Parameter übergeben: AD FS wendetKmsiLifetimeMins
mitDeviceUsageWindowInDays
an. Das erste Aktualisierungstoken verfügt überlifetime=DeviceUsageWindowInDays
, und jede weiteregrant_type=refresh_token
-Anforderung erhält ein neues Aktualisierungstoken. Dieser Prozess wird nur bei nativen Clients oder vertraulichen Clients und Geräteauthentifizierung ausgeführt. - Registrierte Geräte, Geräteauthentifizierung: AD FS verwendet
PersistentSsoLifetimeMins
undDeviceUsageWindowInDays
ähnlich wie KMSI. Sowohl native als auch vertrauliche Clients sollten basierend auf der Geräteauthentifizierung neue Aktualisierungstoken erhalten.
Weitere Informationen finden Sie in der Dokumentation zum einmaligen Anmelden mit AD FS.
Bereiche
Wenn Sie eine Ressource in AD FS registrieren, können Sie Bereiche so konfigurieren, dass AD FS bestimmte Aktionen ausführen kann. Zusätzlich zum Konfigurieren des Bereichs müssen Sie den Bereichswert in der Anforderung senden, damit AD FS die Aktion ausführen kann. Beispielsweise muss ein*e Administrator*in den Bereich während der Ressourcenregistrierung als openid
konfigurieren, und die Anwendung (der Client) muss scope = openid
in der Authentifizierungsanforderung senden, damit AD FS das ID-Token ausstellt. Im Folgenden finden Sie Details zu den verfügbaren Bereichen in AD FS:
aza
: Wenn Sie OAuth 2.0-Protokollerweiterungen für Brokerclients verwenden und der Bereichsparameter den Bereichaza
enthält, gibt der Server ein neues primäres Aktualisierungstoken aus. Das Token wird im Feldrefresh_token
der Antwort festgelegt, undrefresh_token_expires_in field
wird auf die Lebensdauer des neuen primären Aktualisierungstokens festgelegt, wenn eines erzwungen wird.openid
: Ermöglicht der Anwendung, die Verwendung desopenid
Connect-Authentifizierungsprotokolls anzufordern.logon_cert
: Ermöglicht einer Anwendung die Anforderung von Anmeldezertifikaten, mit denen Sie interaktiv authentifizierte Benutzer*innen anmelden können. Der AD FS-Server lässt den Parameteraccess_token
in der Antwort aus und stellt stattdessen eine base64-codierte CMS-Zertifikatkette oder eine vollständige CMC-PKI-Antwort bereit. Weitere Informationen finden Sie unter MS-OAPX: OAuth 2.0 protocol extensions (MS-OAPX: OAuth 2.0-Protokollerweiterungen).user_impersonation
: Fordert ein On-Behalf-Of-Zugriffstoken von AD FS an. Ausführliche Informationen zur Verwendung dieses Bereichs finden Sie unter Migrieren von Anwendungen zur Microsoft Authentication Library (MSAL).allatclaims
: Ermöglicht der Anwendung, anzufordern, dass die Ansprüche im Zugriffstoken auch dem ID-Token hinzugefügt werden.vpn_cert
: Ermöglicht einer Anwendung das Anfordern von VPN-Zertifikaten, mit denen VPN-Verbindungen mithilfe von EAP-TLS-Authentifizierung hergestellt werden. Diese Funktion wird nicht mehr unterstützt.email
: Ermöglicht es einer Anwendung, einen E-Mail-Anspruch für den angemeldeten Benutzer bzw. die angemeldete Benutzerin anzufordern.profile
: Ermöglicht es einer Anwendung, profilbezogene Ansprüche für den angemeldeten Benutzer bzw. die angemeldete Benutzerin anzufordern.
Ansprüche
Von AD FS ausgestellte Sicherheitstoken (Zugriffs- und ID-Token) enthalten Ansprüche oder Assertionen von Informationen zum authentifizierten Antragsteller. Anwendungen können Ansprüche für verschiedene Aufgaben verwenden, z.B. für die folgenden:
- Überprüfen des Tokens
- Identifizieren des Verzeichnismandanten des Antragstellers
- Anzeigen der Benutzerinformationen
- Bestimmen der Autorisierung des Antragstellers
Welche Ansprüche in einem Sicherheitstoken enthalten sind, hängt von der Art des Tokens, von der Art der Anmeldeinformationen für die Benutzerauthentifizierung sowie von der Anwendungskonfiguration ab.
Allgemeiner AD FS-Authentifizierungsablauf
Hier sehen Sie eine Abbildung des allgemeinen Ablaufs:
AD FS empfängt eine Authentifizierungsanforderung vom Client.
AD FS überprüft die Client-ID in der Authentifizierungsanforderung mit der Client-ID, die während der Client- und Ressourcenregistrierung in AD FS abgerufen wurde. Bei Verwendung eines vertraulichen Clients überprüft AD FS dann auch den geheimen Clientschlüssel, der in der Authentifizierungsanforderung angegeben wurde. AD FS überprüft außerdem den Umleitungs-URI des Clients.
AD FS identifiziert die Ressource, auf die der Client über den resource-Parameter zugreifen möchte, der in der Authentifizierungsanforderung übergeben wurde. Wenn Sie die MSAL-Clientbibliothek verwenden, werden keine Ressourcenparameter gesendet. Stattdessen wird die Ressourcen-URL als Teil des Bereichsparameters gesendet: scope = [Ressourcen-URL]/[Bereichswerte, z. B. openid].
Wenn die Ressource nicht mithilfe des resource- oder scope-Parameters übergeben wird, verwendet AD FS eine Standardressource
urn:microsoft:userinfo
, deren Richtlinien (z. B. MFA-, Ausstellungs- oder Autorisierungsrichtlinie) nicht konfiguriert werden können.Als Nächstes überprüft AD FS, ob der Client über die Berechtigungen zum Zugriff auf die Ressource verfügt. AD FS überprüft ferner, ob die Bereiche, die in der Authentifizierungsanforderung übergeben werden, mit den Bereichen übereinstimmen, die beim Registrieren der Ressource konfiguriert wurden. Wenn der Client nicht über die Berechtigungen verfügt oder die richtigen Bereiche nicht in der Authentifizierungsanforderung gesendet werden, wird der Authentifizierungsablauf beendet.
Nachdem Berechtigungen und Bereiche überprüft wurden, authentifiziert AD FS den*die Benutzer*in mithilfe der konfigurierten Authentifizierungsmethode.
Wenn eine zusätzliche Authentifizierungsmethode gemäß der Ressourcenrichtlinie oder der globalen Authentifizierungsrichtlinie erforderlich ist, löst AD FS die zusätzliche Authentifizierung aus.
AD FS verwendet Microsoft Entra Multi-Faktor-Authentifizierung oder Multi-Faktor-Authentifizierung eines Drittanbieters für die Authentifizierung.
Sobald der Benutzer authentifiziert wurde, wendet AD FS die Anspruchsregeln an. Anspruchsregeln bestimmen die Ansprüche, die als Teil der Sicherheitstoken an die Ressource gesendet werden. AD FS wendet auch die Zugriffssteuerungsrichtlinien an, die bestätigen, dass der Benutzer die erforderlichen Bedingungen für den Zugriff auf die Ressource erfüllt.
Als Nächstes generiert AD FS die Zugriffs- und Aktualisierungstoken. AD FS generiert außerdem das ID-Token.
AD FS empfängt die Authentifizierungsanforderung.
Wenn Sie
scope = allatclaims
in die Authentifizierungsanforderung aufnehmen, wird das ID-Token so angepasst, dass es Ansprüche in das Zugriffstoken basierend auf den definierten Anspruchsregeln einschließt.Sobald die erforderlichen Token generiert und angepasst wurden, antwortet AD FS dem Client und nimmt die Token auf. Die ID-Tokenantwort ist nur in der Antwort enthalten, wenn die Authentifizierungsanforderung
scope = openid
enthält. Der Client kann das ID-Token nach der Authentifizierung immer mithilfe des Tokenendpunkts abrufen.
Bibliothekstypen
Sie können zwei Arten von Bibliotheken mit AD FS verwenden:
Clientbibliotheken: Native Clients und Server-Apps verwenden Clientbibliotheken, um Zugriffstoken zum Aufrufen einer Ressource zu erhalten, z. B. eine Web-API. Die Microsoft-Authentifizierungsbibliothek (Microsoft Authentication Library, MSAL) ist die neueste und empfohlene Clientbibliothek bei Verwendung von AD FS 2019.
Bibliotheken der Servermiddleware: Web-Apps nutzen die Bibliotheken der Servermiddleware für die Benutzeranmeldung. Web-APIs nutzen die Bibliotheken der Servermiddleware zum Überprüfen von Token, die von nativen Clients oder anderen Servern gesendet werden. OWIN (Open Web Interface for .NET) ist die empfohlene Middlewarebibliothek.
Anpassen des ID-Tokens (zusätzliche Ansprüche im ID-Token)
In bestimmten Szenarien ist es möglich, dass der Web-App-Client zusätzliche Ansprüche in einem ID-Token benötigt, um die Funktionalität zu unterstützen. Richten Sie zusätzliche Ansprüche in einem ID-Token ein, indem Sie eine der folgenden Optionen verwenden:
Option 1: Verwenden Sie diese Option, wenn ein öffentlicher Client verwendet wird und die Web-App nicht über eine Ressource verfügt, auf die sie zuzugreifen versucht. Diese Option erfordert:
response_mode
ist aufform_post
festgelegt.- Der Bezeichner der vertrauenden Seite (Web-API-Bezeichner) ist mit dem Clientbezeichner identisch.
Option 2: Verwenden Sie diese Option, wenn die Web-App über eine Ressource verfügt, auf die sie zuzugreifen versucht, und zusätzliche Ansprüche über das ID-Token übergeben muss. Sie können sowohl öffentliche als auch vertrauliche Clients verwenden. Diese Option erfordert:
response_mode
ist aufform_post
festgelegt.KB4019472 ist auf Ihren AD FS-Servern installiert.
Der Bereich
allatclaims
ist dem Client-RP-Paar zugewiesen. Sie können den Bereich mithilfe vonGrant-ADFSApplicationPermission
zuweisen. Verwenden SieSet-AdfsApplicationPermission
, wenn die Berechtigung bereits einmal gewährt wurde. Das PowerShell-Cmdlet ist im folgenden Beispiel angegeben:Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"
Weitere Informationen zum Konfigurieren einer Web-App in AD FS zum Abrufen eines angepassten ID-Tokens finden Sie unter Migrieren von Anwendungen zur Microsoft Authentication Library (MSAL).
Einmaliges Abmelden
Das einmalige Abmelden beendet alle Clientsitzungen, die die Sitzungs-ID verwenden. AD FS 2016 und höher unterstützt einmaliges Abmelden für OpenID Connect/OAuth. Weitere Informationen finden Sie unter Einmaliges Abmelden für OpenID Connect mit AD FS.
AD FS-Endpunkte
AD FS-Endpunkt | BESCHREIBUNG |
---|---|
/authorize | AD FS gibt einen Autorisierungscode zurück, den Sie zum Abrufen des Zugriffstokens verwenden können. |
/token | AD FS gibt ein Zugriffstoken zurück, mit dem Sie wie in der Web-API auf die Ressource zugreifen können. |
/userinfo | AD FS gibt den Antragstelleranspruch zurück. |
/devicecode | AD FS gibt den Geräte- und Benutzercode zurück. |
/logout | AD FS meldet den*die Benutzer*in ab. |
/keys | Öffentliche AD FS-Schlüssel, die zum Signieren von Antworten verwendet werden |
/.well-known/openid-configuration | AD FS gibt OAuth-/OpenID Connect-Metadaten zurück. |