Referenz für externe Methodenanbieter für die mehrstufige Microsoft Entra-Authentifizierung (Vorschau)
In diesem Thema wird beschrieben, wie ein externer Authentifizierungsanbieter eine Verbindung mit der Multi-Faktor-Authentifizierung (MFA) von Microsoft Entra herstellt. Ein externer Authentifizierungsanbieter kann in Microsoft Entra ID-Mandanten als externe Authentifizierungsmethode (EAM) integriert werden. Eine EAM kann den zweiten Faktor einer MFA-Anforderung für den Zugriff auf eine Ressource oder Anwendung erfüllen. EAMs erfordern mindestens eine Microsoft Entra ID P1-Lizenz.
Wenn sich ein Benutzer anmeldet, werden diese Mandantenrichtlinien ausgewertet. Die Authentifizierungsanforderungen werden basierend auf der Ressource bestimmt, auf die der Benutzer zugreifen möchte.
Je nach Ihren Parametern gelten möglicherweise mehrere Richtlinien für die Anmeldung. Zu diesen Parametern gehören Benutzer und Gruppen, Anwendungen, Plattform, Anmelderisikostufe und vieles mehr.
Basierend auf den Authentifizierungsanforderungen muss sich der Benutzer möglicherweise mit einem anderen Faktor anmelden, um die MFA-Anforderung zu erfüllen. Der zweite Faktor muss die Art des ersten Faktors ergänzen.
EAMs werden vom Mandantenadministrator zu Microsoft Entra-ID hinzugefügt. Wenn ein Mandant eine EAM für MFA erfordert, wird die Anmeldung als Erfüllung der MFA-Anforderung betrachtet, nachdem Microsoft Entra ID beide validiert hat:
- Der erste mit Microsoft Entra ID abgeschlossene Faktor
- Der zweite mit der EAM abgeschlossene Faktor
Diese Überprüfung erfüllt die MFA-Anforderung für zwei oder mehr Methodentype:
- Etwas, das Sie wissen (Wissen)
- Etwas, das Sie haben (Besitz)
- Etwas, das Sie sind (Inhärenz)
EAMs werden über Open ID Connect (OIDC) implementiert. Für diese Implementierung sind mindestens drei öffentlich zugängliche Endpunkte erforderlich:
- Ein OIDC Discovery-Endpunkt, wie in Ermittlung der Metadaten des Anbieters beschrieben.
- Ein gültiger OIDC-Authentifizierungsendpunkt
- Eine URL, in der die öffentlichen Zertifikate des Anbieters veröffentlicht werden
Sehen wir uns genauer an, wie die Anmeldung mit einer EAM funktioniert:
- Ein Benutzer versucht, sich mit einem ersten Faktor, z. B. einem Kennwort, bei einer Anwendung anzumelden, die durch Microsoft Entra ID geschützt ist.
- Microsoft Entra ID bestimmt, dass ein weiterer Faktor erfüllt werden muss. Beispiel: Eine Richtlinie für bedingten Zugriff erfordert MFA.
- Der Benutzer wählt die EAM als zweiten Faktor aus.
- Microsoft Entra ID leitet die Browsersitzung des Benutzers an die EAM-URL weiter:
- Diese URL wird von der Ermittlungs-URL ermittelt, die von einem Administrator beim Erstellen der EAM bereitgestellt wird.
- Die Anwendung stellt ein abgelaufenes oder fast abgelaufenes Token bereit, das Informationen zum Identifizieren des Benutzers und des Mandanten enthält.
- Der externe Authentifizierungsanbieter überprüft, ob das Token von Microsoft Entra ID stammt, und überprüft den Inhalt des Tokens.
- Der externe Authentifizierungsanbieter ruft optional Microsoft Graph auf, um zusätzliche Informationen über den Benutzer abzurufen.
- Der externe Authentifizierungsanbieter führt alle erforderlichen Aktionen aus, z. B. die Authentifizierung des Benutzers mit einigen Anmeldeinformationen.
- Der externe Authentifizierungsanbieter leitet den Benutzer mit einem gültigen Token, einschließlich aller erforderlichen Ansprüche zurück zu Microsoft Entra ID.
- Microsoft Entra ID überprüft, ob die Signatur des Tokens vom konfigurierten externen Authentifizierungsanbieter stammt, und überprüft dann den Inhalt des Tokens.
- Microsoft Entra ID überprüft das Token anhand der Anforderungen.
- Der Benutzer hat die MFA-Anforderung erfüllt, wenn die Überprüfung erfolgreich ist. Möglicherweise muss der Benutzer auch andere Richtlinienanforderungen erfüllen.
Konfigurieren eines neuen externen Authentifizierungsanbieters mit Microsoft Entra ID
Eine Anwendung, die die Integration darstellt, ist erforderlich, damit EAMs den id_token_hint ausgeben können. Es gibt zwei Möglichkeiten zum Erstellen der Anwendung:
- Erstellt in jedem Mandanten, der den externen Anbieter verwendet.
- Erstellt als eine mehrinstanzenfähige Anwendung. Administratoren mit privilegierter Rolle müssen die Zustimmung erteilen, um die Integration für ihren Mandanten zu aktivieren.
Eine mehrinstanzenfähige Anwendung reduziert die Wahrscheinlichkeit einer Fehlkonfiguration in jedem Mandanten. Außerdem können Anbieter Änderungen an Metadaten vornehmen, z. B. Antwort-URLs an einer zentralen Stelle, anstatt dass jeder Mandant die Änderungen vornehmen muss.
Um eine mehrinstanzenfähige Anwendung zu konfigurieren, muss der Anbieteradministrator zuerst:
Einen Microsoft Entra ID-Mandanten erstellen, falls noch nicht geschehen.
Registrieren Sie eine Anwendung im Mandanten.
Legen Sie die unterstützten Kontotypen der Anwendung auf Konten in einem beliebigen Organisationsverzeichnis (beliebiger Microsoft ID Entra-Mandant – mehrinstanzenfähig) fest.
Fügen Sie der Anwendung die delegierte Berechtigung
openidundprofilevon Microsoft Graph hinzu.Veröffentlichen Sie keine Bereiche in dieser Anwendung.
Fügen Sie der Anwendung gültige authorization_endpoint-URLs des externen Identitätsanbieters als Antwort-URLs hinzu.
Hinweis
Der im Ermittlungsdokument des Anbieters bereitgestellte authorization_endpoint sollte als Umleitungs-URL in der Anwendungsregistrierung hinzugefügt werden. Andernfalls erhalten Sie die folgende Fehlermeldung: ENTRA IDSTS50161: Fehler beim Überprüfen der Autorisierungs-URL des externen Anspruchsanbieters!
Der Prozess der Anwendungsregistrierung erstellt eine Anwendung mit mehreren Eigenschaften. Diese Eigenschaften sind für unser Szenario erforderlich.
| Eigenschaft | Beschreibung |
|---|---|
| ObjectID | Der Anbieter kann die Objekt-ID mit Microsoft Graph verwenden, um die Anwendungsinformationen abzufragen. Der Anbieter kann die Objekt-ID verwenden, um die Anwendungsinformationen programmgesteuert abzurufen und zu bearbeiten. |
| Anwendungs-ID | Der Anbieter kann die Anwendungs-ID als ClientId seiner Anwendung verwenden. |
| URL der Startseite | Die URL der Anbieterhomepage wird nicht verwendet, ist aber im Rahmen der Anwendungsregistrierung erforderlich. |
| Antwort-URLs | Gültige Umleitungs-URLs für den Anbieter. Eine sollte mit der Anbieterhost-URL übereinstimmen, die für den Mandanten des Anbieters festgelegt wurde. Eine der registrierten Antwort-URLs muss mit dem Präfix des authorization_endpoint übereinstimmen, den Microsoft Entra ID über die OIDC-Ermittlung für die Host-URL abruft. |
Eine Anwendung für jeden Mandanten ist auch ein gültiges Modell zur Unterstützung der Integration. Wenn Sie eine Registrierung mit einem einzelnen Mandanten verwenden, muss der Mandantenadministrator eine Anwendungsregistrierung mit den Eigenschaften in der vorherigen Tabelle für eine Einzelmandantenanwendung erstellen.
Hinweis
Die Administratorzustimmung für die Anwendung ist in dem Mandanten erforderlich, der die EAM verwendet. Wenn die Zustimmung nicht erteilt wird, wird der folgende Fehler angezeigt, wenn ein Administrator versucht, die EAM zu verwenden: AADSTS900491: Dienstprinzipal <Ihre App-ID> nicht gefunden.
Konfigurieren optionaler Ansprüche
Ein Anbieter kann weitere Ansprüche mithilfe von optionalen Ansprüchen für id_token konfigurieren.
Hinweis
Unabhängig davon, wie die Anwendung erstellt wird, muss der Anbieter optionale Ansprüche für jede Cloudumgebung konfigurieren. Wenn eine mehrinstanzenfähige Anwendung für Azure weltweit und für Azure für US Government verwendet wird, erfordert jede Cloudumgebung eine andere Anwendung und Anwendungs-ID.
Hinzufügen einer EAM zu Microsoft Entra ID
Informationen zu externen Identitätsanbietern werden in der Richtlinie der Authentifizierungsmethoden jedes Mandanten gespeichert. Die Anbieterinformationen werden als Authentifizierungsmethode des Typs externalAuthenticationMethodConfiguration gespeichert.
Jeder Anbieter hat einen Eintrag im Listenobjekt der Richtlinie. Jeder Eintrag muss Folgendes angeben:
- Ob die Methode aktiviert ist
- Die enthaltenen Gruppen, die die Methode verwenden können
- Die ausgeschlossenen Gruppen, die die Methode nicht verwenden können
Administratoren für bedingten Zugriff können eine Richtlinie mit erforderlicher MFA-Zuweisung erstellen, um die MFA-Anforderung für die Benutzeranmeldung festzulegen. Externe Authentifizierungsmethoden mit Authentifizierungsstärken werden derzeit nicht unterstützt.
Weitere Informationen zum Hinzufügen einer externen Authentifizierungsmethode im Microsoft Entra Admin Center finden Sie unter Verwalten einer externen Authentifizierungsmethode in Microsoft Entra ID (Vorschau).
Microsoft Entra ID-Interaktion mit dem Anbieter
In den nächsten Abschnitten werden die Anbieteranforderungen erläutert und Beispiele für die Interaktion mit Microsoft Entra ID mit einem Anbieter gegeben.
Ermittlung der Metadaten des Anbieters
Ein externer Identitätsanbieter muss einen OIDC Discovery-Endpunkt bereitstellen. Dieser Endpunkt wird verwendet, um weitere Konfigurationsdaten abzurufen. Die vollständige URL, einschließlich .well-known/oidc-configuration, muss in der Discovery-URL enthalten sein, die beim Erstellen des EAM konfiguriert wird.
Der Endpunkt gibt ein dort gehostetes Anbietermetadaten-JSON-Dokument zurück. Der Endpunkt muss auch den gültigen Header der Inhaltslänge zurückgeben.
In der folgenden Tabelle sind die Daten aufgeführt, die in den Metadaten des Anbieters vorhanden sein sollten. Diese Werte sind für dieses Erweiterbarkeitsszenario erforderlich. Das JSON-Metadatendokument kann weitere Informationen enthalten.
Informationen zum OIDC-Dokument mit den Werten für Anbietermetadaten finden Sie unter Anbietermetadaten.
| Metadatenwert | Wert | Kommentare |
|---|---|---|
| Issuer (Aussteller) | Diese URL sollte sowohl mit der Host-URL übereinstimmen, die für die Ermittlung verwendet wird, als auch mit dem iss-Anspruch in den Token, die vom Dienst des Anbieters ausgegeben wurden. | |
| authorization_endpoint | Der Endpunkt, mit dem Microsoft Entra ID für die Autorisierung kommuniziert. Dieser Endpunkt muss als eine der Antwort-URLs für die zulässigen Anwendungen vorhanden sein. | |
| jwks_uri | Wo Microsoft Entra ID die öffentlichen Schlüssel finden kann, die zum Überprüfen der vom Anbieter ausgestellten Signaturen erforderlich sind. [!NOTE] Der JSON-Webschlüssel (JWK) x5c-Parameter muss vorhanden sein, um X.509-Darstellungen der bereitgestellten Schlüssel zu präsentieren. |
|
| scopes_supported | openid | Andere Werte können ebenfalls enthalten sein, sind aber nicht erforderlich. |
| response_types_supported | id_token | Andere Werte können ebenfalls enthalten sein, sind aber nicht erforderlich. |
| subject_types_supported | ||
| id_token_signing_alg_values_supported | Microsoft unterstützt RS256 | |
| claim_types_supported | normal | Diese Eigenschaft ist optional, aber wenn vorhanden, sollte sie den normalen Wert enthalten. Andere Werte können ebenfalls enthalten sein. |
http://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
"authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
"claims_supported": [
"email"
],
"grant_types_supported": [
"implicit"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"issuer": "https://customcaserver.azurewebsites.net",
"jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
"response_modes_supported": [
"form_post"
],
"response_types_supported": [
"id_token"
],
"scopes_supported": [
"openid"
],
"SigningKeys": [],
"subject_types_supported": [
"public"
]
}
http://customcaserver.azurewebsites.net/.well-known/jwks
{
"keys": [
{
"kty": "RSA",
"use": "sig",
"kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
"e": "AQAB",
"x5c": [
"cZa3jz...Wo0rzA="
]
}
]
}
Hinweis
Der JWK x5c-Parameter muss vorhanden sein, um X.509-Darstellungen der bereitgestellten Schlüssel zu präsentieren.
Zwischenspeichern der Anbietermetadaten
Um die Leistung zu verbessern, speichert Microsoft Entra ID Metadaten, die vom Anbieter zurückgegeben werden, einschließlich der Schlüssel. Die Zwischenspeicherung von Anbietermetadaten verhindert, dass immer dann, wenn Microsoft Entra ID mit einem externen Identitätsanbieter spricht, ein Ermittlungsaufruf erforderlich ist.
Dieser Cache wird alle 24 Stunden (täglich) aktualisiert. Hier erfahren Sie, wie wir einen Anbieter für den Rollover ihrer Schlüssel vorschlagen:
- Veröffentlichen des vorhandenen Zertifikats und neuen Zertifikats in „jwks_uri“.
- Signieren mit dem vorhandenen Zertifikat, bis der Microsoft Entra ID-Cache aktualisiert wird oder abgelaufen ist (alle 2 Tage).
- Wechseln zum Signieren mit dem neuen Zertifikat.
Wir veröffentlichen keine Zeitpläne für Schlüsselrollover. Der abhängige Dienst muss darauf vorbereitet sein, sowohl sofortige als auch regelmäßige Rollover zu verarbeiten. Wir empfehlen, zu diesem Zweck eine dedizierte Bibliothek zu verwenden, z. B. azure-activedirectory-identitymodel-extensions-for-dotnet. Weitere Informationen finden Sie unter Rollover von Signaturschlüsseln in Microsoft Entra ID.
Ermittlung von Microsoft Entra ID-Metadaten
Anbieter müssen auch die öffentlichen Schlüssel von Microsoft Entra ID abrufen, um die von Microsoft Entra ID ausgestellten Token zu überprüfen.
Microsoft Entra ID-Metadatenermittlungsendpunkte:
- Azure weltweit:
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration - Azure für US Government (US-Regierungsbehörden):
https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration - Microsoft Azure, betrieben von 21Vianet:
https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration
Mithilfe des öffentlichen Schlüsselbezeichners aus dem Token (das „kid“ aus der JSON Web Signature (JWS)) kann ermittelt werden, welcher der aus der jwks_uri-Eigenschaft abgerufenen Schlüssel verwendet werden soll, um die Microsoft Entra ID-Tokensignatur zu überprüfen.
Überprüfen von Token, die von Microsoft Entra ID ausgestellt wurden
Informationen zum Überprüfen der von Microsoft Entra ID ausgestellten Token finden Sie unter Validierung und ID-Token. Es gibt keine speziellen Schritte für die Verbraucher unserer Ermittlungsmetadaten.
Die -Tokenüberprüfungsbibliothek von Microsoft enthält alle Details zu den Einzelheiten der dokumentierten Tokenüberprüfung, oder sie können beim Durchsuchen des Quellcodes ermittelt werden. Ein Beispiel finden Sie unter Azure-Beispiele.
Nachdem die Überprüfung erfolgreich war, können Sie mit der Anspruchsnutzlast arbeiten, um Details des Benutzers und seines Mandanten abzurufen.
Hinweis
Es ist wichtig, den id_token_hint zu überprüfen, um sicherzustellen, dass der id_token_hint von einem Microsoft-Mandanten stammt und Ihre Integration darstellt. Der id_token_hint sollte vollständig überprüft werden, insbesondere die Signatur, der Zertifikataussteller, die Zielgruppe sowie die anderen Anspruchswerte.
Microsoft Entra ID-Aufruf an den externen Identitätsanbieter
Microsoft Entra ID verwendet den impliziten OIDC-Fluss für die Kommunikation mit dem externen Identitätsanbieter. Bei diesem Ablauf erfolgt die Kommunikation mit dem Anbieter ausschließlich über den Autorisierungsendpunkt des Anbieters. Um dem Anbieter mitzuteilen, für wen Microsoft Entra ID die Anforderung vornimmt, übergibt Microsoft Entra ID ein Token über den id_token_hint-Parameter.
Dieser Aufruf erfolgt über eine POST-Anforderung, da die an den Anbieter übergebene Liste der Parameter groß ist. Eine große Liste verhindert die Verwendung von Browsern, die die Länge einer GET-Anforderung begrenzen.
Die Parameter für die Authentifizierungsanforderung sind in der folgenden Tabelle aufgeführt.
Hinweis
Sofern sie nicht in der folgenden Tabelle aufgeführt sind, sollten andere Parameter in der Anforderung vom Anbieter ignoriert werden.
| Authentifizierungsabfrageparameter | Wert | Beschreibung |
|---|---|---|
| scope | openid | |
| response_type | Id_token | Der für den impliziten Fluss verwendete Wert. |
| response_mode | form_post | Wir verwenden Form-POST, um Probleme mit großen URLs zu vermeiden. Wir erwarten, dass alle Parameter im Textkörper der Anforderung gesendet werden. |
| client_id | Die Client-ID, die vom externen Identitätsanbieter an Microsoft Entra ID übergeben wird, z. B. ABCD. Weitere Informationen finden Sie unter Beschreibung der externen Authentifizierungsmethode. | |
| redirect_url | Der Umleitungs-URI (Uniform Resource Identifier), an den der externe Identitätsanbieter die Antwort sendet (id_token_hint). | |
| Siehe hierzu ein Beispiel im Anschluss an diese Tabelle. | ||
| nonce | Eine zufällige Zeichenfolge, die von Microsoft Entra ID generiert wird. Dies kann die Sitzungs-ID sein. Falls bereitgestellt, muss sie in der Antwort an Microsoft Entra ID zurückgegeben werden. | |
| state | Falls übergeben, sollte der Anbieter den Status in seiner Antwort zurückgeben. Microsoft Entra ID verwendet den Status, um Kontext zum Aufruf beizubehalten. | |
| id_token_hint | Ein Token, das von Microsoft Entra ID für den Endbenutzer ausgestellt und zum Vorteil des Anbieters übergeben wird. | |
| claims | Ein JSON-Blob, das die angeforderten Ansprüche enthält. Ausführliche Informationen zum Format dieses Parameters finden Sie unter Anspruchsanforderungsparameter in der OIDC-Dokumentation und ein Beispiel nach dieser Tabelle. | |
| client-request-id | Ein GUID-Wert | Ein Anbieter kann diesen Wert protokollieren, um Probleme zu beheben. |
Beispiel für einen Umleitungs-URI
Die Umleitungs-URIs (Uniform Resource Identifiers) sollten beim Anbieter off-band registriert werden. Die Umleitungs-URIs, die gesendet werden können, sind:
- Azure weltweit:
https://login.microsoftonline.com/common/federation/externalauthprovider - Azure für US Government (US-Regierungsbehörden):
https://login.microsoftonline.us/common/federation/externalauthprovider - Microsoft Azure, betrieben von 21Vianet:
https://login.partner.microsoftonline.cn/common/federation/externalauthprovider
Beispiel für eine EAM, die MFA erfüllt
Hier ist ein Beispiel für eine Authentifizierung, bei der eine EAM MFA erfüllt. Dieses Beispiel hilft einem Anbieter zu erfahren, welche Ansprüche Microsoft Entra ID erwartet.
Die Kombination der Werte acr und amr wird von Microsoft Entra ID verwendet, um Folgendes zu überprüfen:
- Die für den zweiten Faktor verwendete Authentifizierungsmethode erfüllt die MFA-Anforderung.
- Die Authentifizierungsmethode unterscheidet sich von der Methode, die zum Abschließen des ersten Faktors für die Anmeldung bei Microsoft Entra ID verwendet wird.
{
"id_token": {
"acr": {
"essential": true,
"values":["possessionorinherence"]
},
"amr": {
"essential": true,
"values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
}
}
}
Standardmäßige Id_token_hint-Ansprüche
In diesem Abschnitt werden die erforderlichen Inhalte des Token beschrieben, die als id_token_hint in der Anforderung an den Anbieter übergeben werden. Das Token kann mehr Ansprüche enthalten als in der folgenden Tabelle.
| Anspruch | Wert | Beschreibung |
|---|---|---|
| Iss | Identifiziert den Sicherheitstokendienst (STS), der das Token und den Microsoft Entra ID-Mandanten, in dem der Benutzer authentifiziert wurde, erstellt und zurückgibt. Ihre App sollte ggf. den GUID-Teil des Anspruchs verwenden, um die Mandanten einzuschränken, die sich bei der App anmelden können. Der Zertifikataussteller sollte mit der Zertifikataussteller-URL aus den JSON-Metadaten der OIDC-Ermittlung für den Mandanten übereinstimmen, in dem sich der Benutzer angemeldet hat. | |
| aud | Die Zielgruppe sollte auf die Client-ID des externen Identitätsanbieters für Microsoft Entra ID festgelegt werden. | |
| exp | Die Ablaufzeit ist so festgelegt, dass sie kurz nach der Ausgabezeit abläuft, um Zeitversatzprobleme zu vermeiden. Da dieses Token nicht für die Authentifizierung vorgesehen ist, gibt es keinen Grund, warum seine Gültigkeit die Anfrage lange überdauern sollte. | |
| Iat | Legen Sie die Ausgabezeit wie gewohnt fest. | |
| tid | Die Mandanten-ID dient zum Anzeigen des Mandanten gegenüber dem Anbieter. Sie stellt den Microsoft Entra ID-Mandanten dar, von dem der Benutzer stammt. | |
| oid | Der unveränderliche Bezeichner für ein Objekt in der Microsoft Identity Platform. In diesem Fall handelt es sich um ein Benutzerkonto. Er kann auch verwendet werden, um Autorisierungsüberprüfungen auf sichere Weise durchzuführen, und er kann als Schlüssel in Datenbanktabellen genutzt werden. Mit dieser ID wird der Benutzer anwendungsübergreifend eindeutig identifiziert. Zwei verschiedene Anwendungen, die den gleichen Benutzer anmelden, erhalten den gleichen Wert im oid-Anspruch. Somit kann oid in Abfragen an Microsoft-Onlinedienste wie Microsoft Graph verwendet werden. | |
| preferred_username | Ein lesbarer Wert, der Aufschluss über den Antragsteller des Tokens gibt. Dieser Wert ist innerhalb eines Mandanten nicht zwingend eindeutig. Er dient daher nur zu Anzeigezwecken. | |
| sub | Antragstellerbezeichner für den Endbenutzer am Zertifikataussteller. Der Prinzipal, für den das Token Informationen bestätigt (beispielsweise der Benutzer einer Anwendung). Dieser Wert ist unveränderlich und kann nicht erneut zugewiesen oder wiederverwendet werden. Er kann für die sichere Durchführung von Autorisierungsüberprüfungen verwendet werden, z.B. wenn das Token verwendet wird, um auf eine Ressource zuzugreifen. Er kann auch als Schlüssel in Datenbanktabellen verwendet werden. Da der Antragsteller immer in den Token vorhanden ist, die Microsoft Entra ID ausstellt, empfehlen wir die Nutzung dieses Werts in einem allgemeinen Autorisierungssystem. Der Antragsteller ist allerdings ein paarweiser Bezeichner: Er gilt nur für eine bestimmte Anwendungs-ID. Wenn sich ein Benutzer also bei zwei verschiedenen Anwendungen mit zwei verschiedenen Client-IDs anmeldet, erhalten diese Anwendungen zwei unterschiedliche Werte für den Antragstelleranspruch. Dieses Ergebnis kann abhängig von den Architektur- und Datenschutzanforderungen möglicherweise wünschenswert sein oder nicht. Siehe auch den oid-Anspruch (der innerhalb eines Mandanten für alle Apps immer gleich bleibt). |
Um zu verhindern, dass er für etwas anderes als einen Hinweis verwendet wird, wird das Token als abgelaufen ausgegeben. Das Token ist signiert und kann mithilfe der veröffentlichten Microsoft Entra ID-Ermittlungsmetadaten überprüft werden.
Optionale Ansprüche von Microsoft Entra ID
Wenn ein Anbieter optionale Ansprüche von Microsoft Entra ID benötigt, können Sie diese optionalen Ansprüche für id_token konfigurieren. Weitere Informationen finden Sie unter Optionale Ansprüche.
Empfohlene Verwendung von Ansprüchen
Microsoft empfiehlt, Konten auf der Anbieterseite mit dem Konto in Azure AD mithilfe der oid- und tid-Ansprüche zu verknüpfen. Diese beiden Ansprüche sind für das Konto im Mandanten garantiert eindeutig.
Beispiel eines id_token_hint
Hier ist ein Beispiel für einen id_token_hint für ein Verzeichnismitglied:
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "Test User 2",
"preferred_username": "testuser2@contoso.com"
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
Hier ist ein Beispiel für den id_token-Hinweis für einen Gastbenutzer im Mandanten:
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "External Test User (Hotmail)",
"preferred_username": "externaltestuser@hotmail.com",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
Vorgeschlagene Aktionen für externe Identitätsanbieter
Wir empfehlen, dass externe Identitätsanbieter diese Schritte ausführen. Die Liste ist nicht vollständig, und Anbieter sollten andere angemessene Überprüfungsschritte ausführen.
- Aus der Anforderung:
- Stellen Sie sicher, dass der redirect_uri im Microsoft Entra ID-Aufruf an den externen Identitätsanbieter veröffentlicht wird.
- Stellen Sie sicher, dass die client_id Microsoft Entra ID einen Wert zugewiesen hat, z. B. ABCD.
- Der Anbieter sollte zunächst den id_token_hint überprüfen, der ihm von Microsoft Entra ID präsentiert wird.
- Aus den Ansprüchen im id_token_hint:
- Sie können optional einen Aufruf an Microsoft Graph tätigen, um weitere Details zu diesem Benutzer abzurufen. Die oid- und tid-Ansprüche im id_token_hint sind in diesem Zusammenhang nützlich. Ausführliche Informationen zu den im id_token_hint bereitgestellten Ansprüchen finden Sie unter Standardmäßige id_token_hint-Ansprüche.
- Führen Sie dann alle anderen Authentifizierungsaktivitäten durch, für die das Produkt des Anbieters erstellt wurde.
- Je nach dem Ergebnis der Aktionen des Benutzers und anderen Faktoren würde der Anbieter dann eine Antwort erstellen und an Microsoft Entra ID zurücksenden, wie im nächsten Abschnitt erläutert.
Verarbeitung der Anbieterantwort durch Microsoft Entra ID
Der Anbieter muss eine Antwort zurück an den redirect_uri bereitstellen. Die folgenden Parameter sollten für eine erfolgreiche Antwort bereitgestellt werden:
| Parameter | Wert | Beschreibung |
|---|---|---|
| id_token | Das vom externen Identitätsanbieter ausgestellte Token. | |
| state | Derselbe Status, der in der Anforderung übergeben wurde, falls vorhanden. Andernfalls sollte dieser Wert nicht vorhanden sein. |
Bei Erfolg würde der Anbieter dann einen id_token für den Benutzer ausstellen. Microsoft Entra ID verwendet die veröffentlichten OIDC-Metadaten, um zu überprüfen, ob das Token die erwarteten Ansprüche enthält, und führt eine andere Überprüfung des von OIDC benötigten Tokens durch.
| Anspruch | Wert | Beschreibung |
|---|---|---|
| Iss | Zertifikataussteller: muss mit dem Zertifikataussteller aus den Ermittlungsmetadaten des Anbieters übereinstimmen. | |
| aud | Zielgruppe: die Client-ID von Microsoft Entra ID. Beachten Sie die client_id in Microsoft Entra ID-Aufruf an den externen Identitätsanbieter. | |
| exp | Ablaufzeit: wie gewohnt festgelegt. | |
| Iat | Ausgabezeit: wie gewohnt festlegen. | |
| sub | Betreff: muss mit dem Sub des id_token_hint übereinstimmen, der gesendet wurde, um diese Anforderung zu initiieren. | |
| nonce | Derselbe Status, der in der Anforderung übergeben wurde, falls vorhanden. | |
| acr | Die acr-Ansprüche für die Authentifizierungsanforderung. Dieser Wert sollte mit einem der Werte der Anforderung übereinstimmen, die gesendet wurden, um diese Anforderung zu initiieren. Es sollte nur ein acr-Anspruch zurückgegeben werden. Eine Liste der Ansprüche finden Sie unter Unterstützte acr-Ansprüche. | |
| amr | Die amr-Ansprüche für die Authentifizierungsmethode, die für die Authentifizierung verwendet wird. Dieser Wert sollte als Array zurückgegeben werden, und es sollte ur ein Methodenanspruch zurückgegeben werden. Eine Liste der Ansprüche finden Sie unter Unterstützte acr-Ansprüche. |
Unterstützte acr-Ansprüche
| Anspruch | Hinweise |
|---|---|
| possessionorinherence | Die Authentifizierung muss mit einem besitz- oder inhärenzbasierten Faktor erfolgen. |
| knowledgeorpossession | Die Authentifizierung muss mit einem wissens- oder besitzbasierten Faktor erfolgen. |
| knowledgeorinherence | Die Authentifizierung muss mit einem wissens- oder inhärenzbasierten Faktor erfolgen. |
| knowledgeorpossessionorinherence | Die Authentifizierung muss mit einem wissens- oder besitz- oder inhärenzbasierten Faktor erfolgen. |
| knowledge | Die Authentifizierung muss mit einem wissensbasierten Faktor erfolgen. |
| possession | Die Authentifizierung muss mit einem besitzbasierten Faktor erfolgen. |
| inherence | Die Authentifizierung muss mit einem inhärenzbasierten Faktor erfolgen. |
Unterstützte amr-Ansprüche
| Anspruch | Hinweise |
|---|---|
| face | Biometrie mit Gesichtserkennung |
| fido | FIDO2 wurde verwendet |
| fpt | Biometrie mit Fingerabdruck |
| hwk | Nachweis des Besitzes von hardwaregesicherten Schlüsseln |
| iris | Biometrie mit Irisscan |
| otp | Einmalkennwort |
| pop | Proof of Possession (Besitznachweis) |
| retina | Biometrie des Netzhautscans |
| SC | Smartcard |
| sms | Bestätigung durch Text an registrierte Nummer |
| swk | Bestätigung des Vorhandenseins eines softwaresicherten Schlüssels |
| tel | Bestätigung per Telefon |
| vbm | Biometrie mit Stimmabdruck |
Microsoft Entra ID erfordert, dass MFA erfüllt ist, um ein Token mit MFA-Ansprüchen auszustellen. Daher können nur Methoden mit einem anderen Typ die zweite Faktoranforderung erfüllen. Wie bereits erwähnt, sind die verschiedenen Methodentypen, die verwendet werden können, um den zweiten Faktor zu erfüllen, Wissen, Besitz und Inhärenz.
Microsoft Entra ID überprüft die Typzuordnung basierend auf der folgenden Tabelle.
| Claim-Methode | type | Notizen |
|---|---|---|
| face | Inhärenz | Biometrie mit Gesichtserkennung |
| fido | Besitz | FIDO2 wurde verwendet. Einige Implementierungen erfordern möglicherweise auch Biometrie, aber der Methodentyp Besitz wird zugeordnet, da es sich um das primäre Sicherheitsattribute handelt. |
| fpt | Inhärenz | Biometrie mit Fingerabdruck |
| hwk | Besitz | Nachweis des Besitzes von hardwaregesicherten Schlüsseln |
| iris | Inhärenz | Biometrie mit Irisscan |
| otp | Besitz | Einmalkennwort |
| pop | Besitz | Proof of Possession (Besitznachweis) |
| retina | Inhärenz | Biometrie des Netzhautscans |
| SC | Besitz | Smartcard |
| sms | Besitz | Bestätigung durch Text an registrierte Nummer |
| swk | Besitz | Nachweis des Vorhandenseins eines softwaresicherten Schlüssels |
| tel | Besitz | Bestätigung per Telefon |
| vbm | Inhärenz | Biometrie mit Stimmabdruck |
Wenn keine Probleme mit dem Token gefunden werden, hält Microsoft Entra ID MFA für erfüllt und gibt ein Token an den Endbenutzer aus. Andernfalls schlägt die Anforderung des Endbenutzers fehl.
Der Fehler wird durch das Ausgeben von Fehlerantwortparametern angezeigt.
| Parameter | Wert | Beschreibung |
|---|---|---|
| Fehler | Ein ASCII-Fehlercode, z. B. access_denied oder temporarily_unavailable. |
Microsoft Entra ID betrachtet die Anforderung als erfolgreich, wenn der parameter id_token in der Antwort vorhanden ist und wenn das Token gültig ist. Andernfalls gilt die Anforderung als erfolglos. Microsoft Entra ID verweigert den ursprünglichen Authentifizierungsversuch aufgrund der Anforderungen der Richtlinie für bedingten Zugriff.
Microsoft Entra ID verwirft den Status des Authentifizierungsversuchs auf seiner Seite etwa 10 Minuten nach der Weiterleitung an den Anbieter.
Behandlung von Microsoft Entra ID-Fehlerantworten
Microsoft Azure-Dienste verwenden eine Korrelations-ID, um Aufrufe über verschiedene interne und externe Systeme hinweg zu korrelieren. Diese dient als allgemeiner Bezeichner des gesamten Vorgangs oder Flusses, der potenziell mehrere HTTP-Aufrufe umfasst. Wenn während eines der Vorgänge ein Fehler auftritt, enthält die Antwort ein Feld mit dem Namen „Korrelations-ID“.
Wenn Sie sich an den Microsoft-Support oder einen ähnlichen Dienst wenden, stellen Sie den Wert dieser Korrelations-ID bereit, da sie dazu beiträgt, schneller auf die Telemetrie und Protokolle zuzugreifen.
Zum Beispiel:
ENTRA IDSTS70002: Fehler beim Überprüfen der Anmeldeinformationen. ENTRA IDSTS50012: Fehler bei Signaturüberprüfung für das Token für die externe ID vom Aussteller „https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa“. KeyID des Tokens ist "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u" Ablaufverfolgungs-ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333 Korrelations-ID: aaaa0000-bb11-2222-33cc-444444dddddd Timestamp: 2023-07-24 16:51:34Z
Benutzerdefinierte Steuerelemente und EAMs
In Microsoft Entra ID können EAMs und benutzerdefinierte Steuerelemente für bedingten Zugriff parallel ausgeführt werden, während Kunden sich auf EAMs vorbereiten und zu EAMs migrieren.
Kunden, die derzeit eine Integration mit einem externen Anbieter mithilfe von benutzerdefinierten Steuerelementen verwenden, können sie weiterhin verwenden, ebenso wie alle Richtlinien für bedingten Zugriff, die sie für die Verwaltung des Zugriffs konfiguriert haben. Administratoren wird empfohlen, während des Migrationszeitraums einen parallelen Satz von Richtlinien für bedingten Zugriff zu erstellen:
Die Richtlinien sollten die Gewährung Erfordern der Multi-Faktor-Authentifizierung anstelle der Gewährung mit benutzerdefinierten Steuerelementen verwenden.
Hinweis
Die Berechtigungskontrollen, die auf der Authentifizierungsstärke basieren, einschließlich der integrierten MFA-Stärke, werden von der EAM nicht erfüllt. Richtlinien sollten nur mit Erfordern der Multi-Faktor-Authentifizierung konfiguriert werden. Wir arbeiten aktiv daran, EAMs mit Authentifizierungsstärken zu unterstützen.
Die neue Richtlinie kann zuerst mit einer Teilmenge von Benutzern getestet werden. Die Testgruppe würde von der Richtlinie ausgeschlossen, die die benutzerdefinierten Steuerelemente erfordert, und in die Richtlinie eingeschlossen, die MFA erfordert. Sobald der Administrator sich sicher ist, dass die Richtlinie, die MFA erfordert, von der EAM erfüllt wird, kann der Administrator alle erforderlichen Benutzer in die Richtlinie mit der MFA-Erteilung aufnehmen, und die Richtlinie, die für benutzerdefinierte Steuerelemente konfiguriert ist, kann in Aus verschoben werden.
Integrationsunterstützung
Wenn beim Erstellen der EAM-Integration mit Microsoft Entra ID Probleme auftreten, kann der unabhängige Lösungsanbieter (Independent Solution Provider, ISV) von Microsoft Customer Experience Engineering (CxE) möglicherweise helfen. Um mit dem CxE ISV-Team in Kontakt zu treten, übermitteln Sie eine Anfrage zur Unterstützung.
References
Glossar
| Begriff | Beschreibung |
|---|---|
| MFA | Multi-Faktor-Authentifizierung. |
| EAM | Eine externe Authentifizierungsmethode ist eine Authentifizierungsmethode von einem anderen Anbieter als Microsoft Entra ID, die als Teil der Authentifizierung eines Benutzers verwendet wird. |
| OIDC | Open ID Connect ist ein Authentifizierungsprotokoll, das auf OAuth 2.0 basiert. |
| 00001111-aaaa-2222-bbbb-3333cccc4444 | Ein Beispiel für eine appid, die für eine externe Authentifizierungsmethode integriert ist. |
Nächste Schritte
Weitere Informationen zum Konfigurieren einer EAM in Microsoft Entra Admin Center finden Sie unter Verwalten einer externen Authentifizierungsmethode in Microsoft (Vorschau).
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Einreichen und Feedback anzeigen für