Freigeben über

Entwicklerleitfaden für Microsoft Entra bedingten Zugriff

Gilt für: Grüner Kreis mit einem weißen Häkchensymbol, das angibt, dass der folgende Inhalt für Mitarbeiter(-)Mandanten gilt. Mitarbeiter(-)Mandanten (weitere Informationen)

Das Feature „Bedingter Zugriff“ in Microsoft Entra ID ist eine von mehreren Optionen, mit denen Sie Ihre App und einen Dienst schützen können. Der bedingte Zugriff ermöglicht Entwicklern und Unternehmenskunden den Schutz von Diensten auf unterschiedliche Weise, einschließlich:

  • Mehrstufige Authentifizierung
  • Ermöglicht nur bei Intune registrierten Geräten den Zugriff auf bestimmte Dienste
  • Einschränken von Benutzerstandorten und IP-Adressbereichen

Im Artikel „Was ist bedingter Zugriff?” finden Sie weitere Informationen zu allen Funktionen des bedingten Zugriffs.

Für Entwickler, die Apps für Microsoft Entra ID erstellen, wird in diesem Artikel veranschaulicht, wie der bedingte Zugriff eingesetzt werden kann. Außerdem werden die Auswirkungen des Zugriffs auf Ressourcen beschrieben, über die Sie keine Kontrolle haben und auf die ggf. Richtlinien für den bedingten Zugriff angewendet werden. Darüber hinaus geht es im Artikel um die Auswirkungen des bedingten Zugriffs auf den „Im Auftrag von“-Ablauf, auf Web-Apps, auf den Zugriff auf Microsoft Graph und auf das Aufrufen von APIs.

Kenntnisse von Einzelnen - und Mehrinstanzen-Apps und gängigen Authentifizierungsmustern werden vorausgesetzt.

Hinweis

Für die Verwendung dieses Features wird eine Microsoft Entra ID P1-Lizenz benötigt. Um die richtige Lizenz für Ihre Anforderungen zu ermitteln, lesen Sie Vergleich: Allgemein verfügbare Features der Editionen Free, Basic und Premium. Kunden mit Microsoft 365 Business-Lizenzen haben auch Zugriff auf Funktionen für bedingten Zugriff.

Welche Auswirkungen hat der bedingte Zugriff auf eine App?

Betroffene App-Typen

In den häufigsten Fällen ändert der bedingte Zugriff das Verhalten einer App nicht oder erfordert Änderungen vom Entwickler. Nur in bestimmten Fällen, wenn eine App im Hintergrund oder indirekt ein Token für einen Dienst anfordert, sind Änderungen am Code einer App erforderlich, um die besonderen Anforderungen des bedingten Zugriffs zu erfüllen. Es kann so einfach sein, wie eine Anforderung für die interaktive Anmeldung auszuführen.

Insbesondere die folgenden Szenarien erfordern Code zum Behandeln der speziellen Anforderungen des bedingten Zugriffs:

  • Apps, die den On-Behalf-Of-Fluss ausführen
  • Apps mit Zugriff auf mehrere Dienste/Ressourcen
  • Single-Page-Apps, die MSAL.js verwenden
  • Web-Apps, die eine Ressource aufrufen

Sie können Richtlinien für den bedingten Zugriff auf die App anwenden, aber auch auf eine Web-API, auf die Ihre App zugreift. Weitere Informationen zum Konfigurieren einer Richtlinie für bedingten Zugriff finden Sie unter Schnellstart: Anfordern der mehrstufigen Authentifizierung (Multi-Factor Authentication, MFA) für bestimmte Apps über den bedingten Zugriff von Microsoft Entra.

Abhängig vom jeweiligen Szenario können Unternehmenskunden jederzeit Richtlinien für den bedingten Zugriff anwenden und entfernen. Damit Ihre App beim Anwenden einer neuen Richtlinie weiterhin funktioniert, implementieren Sie die Behandlung der speziellen Anforderungen. Die folgenden Beispiele veranschaulichen die Behandlung dieser Anforderungen.

Beispiele für den bedingten Zugriff

Einige Szenarien erfordern Änderungen am Code, um den bedingten Zugriff nutzen zu können, während andere ohne Änderungen funktionieren. Hier sind einige Szenarien, in denen der bedingte Zugriff verwendet wird, um eine mehrstufige Authentifizierung durchzuführen, die einen Einblick in den Unterschied gibt.

  • Sie erstellen eine iOS-App mit nur einem Mandanten und wenden eine Richtlinie für den bedingten Zugriff an. Die App meldet einen Benutzer an, aber fordert keinen Zugriff auf eine API an. Wenn sich der Benutzer anmeldet, wird die Richtlinie automatisch aufgerufen, und der Benutzer muss mehrstufige Authentifizierung (MFA) ausführen.
  • Sie erstellen eine systemeigene App, die einen Dienst auf mittlerer Ebene verwendet, um auf eine downstream-API zuzugreifen. Ein Unternehmenskunde, der diese App verwendet, wendet eine Richtlinie für die Downstream-API an. Wenn sich ein Endbenutzer anmeldet, fordert die native App Zugriff auf die mittlere Ebene an und sendet das Token. Die mittlere Ebene führt den „Im Auftrag von“-Ablauf aus, um Zugriff auf die Downstream-API anzufordern. An diesem Punkt wird der mittleren Ebene eine Anspruchanforderung übermittelt. Die mittlere Ebene sendet die Anforderung wieder an die native App, die ihrerseits die Richtlinie für den bedingten Zugriff erfüllen muss.

Microsoft Graph

Für Microsoft Graph gelten besondere Überlegungen beim Erstellen von Apps in Umgebungen mit bedingtem Zugriff. Im Allgemeinen verhalten sich die Mechanismen des bedingtem Zugriffs gleich, aber die Richtlinien, die Ihre Benutzer sehen, basieren auf den zugrunde liegenden Daten, die Ihre App vom Diagramm anfordert.

Insbesondere stellen alle Microsoft Graph-Bereiche ein bestimmtes Dataset dar, auf das individuelle Richtlinien angewendet werden können. Da Richtlinien für bedingten Zugriff den spezifischen Datensätzen zugewiesen werden, erzwingt die Microsoft Entra-ID Richtlinien für bedingten Zugriff basierend auf den Daten hinter Graph und nicht Graph selbst.

Wenn eine App beispielsweise die folgenden Microsoft Graph-Bereiche anfordert,

scopes="ChannelMessages.Read.All Mail.Read"

Eine App kann fordern, dass ihre Benutzer alle Richtlinien erfüllen, die in Teams und Exchange festgelegt sind. Einigen Bereichen können mehrere Datasets zugeordnet sein, wenn der Zugriff gewährt wird.

Einhaltung einer Richtlinie für bedingten Zugriff

Bei mehreren verschiedenen App-Topologien wird beim Einrichten der Sitzung eine Richtlinie für den bedingten Zugriff ausgewertet. Da Richtlinien für den bedingten Zugriff auf App- und Dienstebene ausgeführt werden, hängt der Zeitpunkt ihres Aufrufs stark vom jeweiligen Szenario ab.

Wenn Ihre App versucht, auf einen Dienst zuzugreifen, der mit einer Richtlinie für den bedingten Zugriff geschützt ist, kann sie auf eine Herausforderung für den bedingten Zugriff stoßen. Diese Anforderung wird im claims-Parameter codiert, der in einer Antwort von Microsoft Entra ID empfangen wird. Dies ist ein Beispiel für diesen Anforderungsparameter:

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Entwickler können diese Anforderung annehmen und an eine neue Anforderung an Microsoft Entra ID anfügen. Beim Durchlaufen dieses Zustands werden die Endbenutzer zum Ausführen aller erforderlichen Aktionen zur Einhaltung der Richtlinie für den bedingten Zugriff aufgefordert. In den folgenden Szenarien werden Einzelheiten des Fehlers und das Extrahieren des Parameters erläutert.

Szenarien

Voraussetzungen

Microsoft Entra Bedingter Zugriff ist ein Feature, das in Microsoft Entra ID P1 oder P2 enthalten ist. Kunden mit Microsoft 365 Business-Lizenzen haben auch Zugriff auf Funktionen für bedingten Zugriff.

Überlegungen für bestimmte Szenarien

Die folgenden Informationen gelten nur in diesen Conditional Access-Szenarien:

  • Apps, die den On-Behalf-Of-Fluss ausführen
  • Apps mit Zugriff auf mehrere Dienste/Ressourcen
  • Single-Page-Apps, die MSAL.js verwenden

In den folgenden Abschnitten werden allgemeine Szenarien beschrieben, die komplexer sind. Das grundlegende Prinzip dabei ist, dass Richtlinien für den bedingten Zugriff zu dem Zeitpunkt ausgewertet werden, zu dem das Token für einen Dienst mit einer Richtlinie für den bedingten Zugriff angefordert wird.

Szenario: App für den Ablauf vom Typ „Im Auftrag von“

In diesem Szenario wird der Fall behandelt, bei dem eine native App einen Webdienst bzw. eine API aufruft. Der Dienst wiederum führt den Flow „On-Behalf-Of“ aus, um einen Downstreamdienst aufzurufen. In diesem Fall haben wir die Richtlinie für den bedingten Zugriff auf den Downstreamdienst (Web-API 2) angewendet und verwenden eine native App anstelle einer Server-/Daemon-App.

Flussdiagramm für Apps mit „Im Auftrag von“-Ablauf

Die anfängliche Tokenanforderung für Web-API 1 fordert den Endbenutzer nicht zur mehrstufigen Authentifizierung auf, da Web-API 1 möglicherweise nicht immer auf die downstreame API trifft. Sobald Web-API 1 versucht, ein Token im Auftrag des Benutzers für Web-API 2 anzufordern, schlägt die Anforderung fehl, da sich der Benutzer nicht mit mehrstufiger Authentifizierung angemeldet hat.

Microsoft Entra ID gibt eine HTTP-Antwort mit interessanten Daten zurück:

Hinweis

In diesem Fall ist dies eine Fehlerbeschreibung für die mehrstufige Authentifizierung, aber es gibt eine Vielzahl von interaction_required-Fehlern mit Bezug auf den bedingten Zugriff.

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multifactor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

In Web-API 1 fangen wir den Fehler error=interaction_required ab und senden die claims-Anforderung an die Desktop-App zurück. An diesem Punkt kann die Desktop-App einen neuen acquireToken()-Aufruf erstellen und die claims-Anforderung als zusätzlichen Parameter an die Abfragezeichenfolge anfügen. Diese neue Anforderung fordert den Benutzer zum Durchführen einer Multi-Faktor-Authentifizierung auf, sendet das neue Token an die Web-API 1 zurück und schließt den Im-Auftrag-von-Ablauf ab.

Wenn Sie dieses Szenario testen möchten, sehen Sie sich unser .NET-Codebeispiel an. Es zeigt, wie die Anspruchanforderung von der Web-API 1 zurück an die native App übergeben und in der Client-App eine neue Anforderung erstellt wird.

Szenario: App, die auf mehrere Dienste zugreift

In diesem Szenario wird der Fall behandelt, bei dem eine Web-App auf zwei Dienst zugreift, von denen für einen eine Richtlinie für den bedingten Zugriff gilt. Abhängig von Ihrer App-Logik gibt es möglicherweise einen Pfad, in dem Ihre App keinen Zugriff auf beide Webdienste benötigt. In diesem Szenario spielt die Reihenfolge, in der Sie ein Token anfordern, eine wichtige Rolle für den Endbenutzer.

Wir gehen von den beiden Webdiensten A und B aus, wobei für Webdienst B unsere Richtlinie für den bedingten Zugriff gilt. Während die anfängliche interaktive Authentifizierungsanforderung Zustimmung für beide Dienste erfordert, ist die Richtlinie für den bedingten Zugriff nicht in allen Fällen erforderlich. Wenn die App ein Token für den Webdienst B anfordert, wird die Richtlinie aufgerufen, wodurch nachfolgende Anforderungen an den Webdienst A ebenfalls erfolgreich sind.

Flussdiagramm für Apps mit Zugriff auf mehrere Dienste

Wenn andererseits die App zunächst ein Token für den Webdienst A anfordert, ruft der Endbenutzer damit nicht die Richtlinie für den bedingten Zugriff auf. So kann der App-Entwickler die Endbenutzererfahrung steuern, indem er die Richtlinie für den bedingten Zugriff nicht in allen Fällen erzwingt. Der schwierige Fall ist, wenn die App später ein Token für Webdienst B anfordert. An diesem Punkt muss der Endbenutzer die Richtlinie für bedingten Zugriff einhalten. Wenn die App acquireToken versucht, wird möglicherweise die folgende Fehlermeldung generiert (in der folgenden Abbildung dargestellt):

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multifactor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

App mit Zugriff auf mehrere Dienste fordert ein neues Token an.

Wenn die App die MSAL-Bibliothek verwendet, wird bei einem Fehler beim Abrufen des Tokens immer interaktiv ein Wiederholungsversuch ausgeführt. Bei dieser interaktiven Anforderung hat der Endbenutzer die Möglichkeit, die Anforderungen für den bedingten Zugriff zu erfüllen. Dies gilt immer, außer wenn es sich um eine AcquireTokenSilentAsync- oder PromptBehavior.Never-Anforderung handelt. In diesem Fall muss die App eine interaktive AcquireToken-Anforderung ausführen, damit der Endbenutzer die Richtlinie erfüllen kann.

Szenario: Single-Page-App (SPA), die MSAL.js verwendet

In diesem Szenario betrachten wir den Fall, in dem wir eine Einzel-Seiten-App (SPA) haben, die eine zum Aufrufen einer durch den bedingten Zugriff geschützten Web-API mit MSAL.js verwendet. Dies ist eine einfache Architektur, die jedoch einige Feinheiten beinhaltet, die bei der Entwicklung für bedingten Zugriff berücksichtigt werden müssen.

In MSAL.js sind einige Funktionen vorhanden, die Token erhalten: acquireTokenSilent(), acquireTokenPopup(), und acquireTokenRedirect().

  • acquireTokenSilent() kann verwendet werden, um stillschweigend ein Zugriffstoken zu erhalten, was bedeutet, dass es unter keinen Umständen auf der Benutzeroberfläche angezeigt wird.
  • acquireTokenPopup() und acquireTokenRedirect() werden beide verwendet, um interaktiv ein Token für eine Ressource anzufordern – beide zeigen also immer eine Benutzeroberfläche für die Anmeldung an.

Wenn eine App zum Aufrufen einer Web-API ein Zugriffstoken benötigt, versucht sie einen Aufruf von acquireTokenSilent(). Wenn das Token abgelaufen ist oder wir eine Richtlinie für den bedingten Zugriff einhalten müssen, schlägt die Funktion acquireToken fehl und die App verwendet acquireTokenPopup() or acquireTokenRedirect().

Flussdiagramm für Single-Page-App mit MSAL

Im Folgenden finden Sie ein Beispiel für das Szenario für den bedingten Zugriff. Der Endbenutzer hat die Website gerade erst aufgerufen und verfügt noch nicht über eine Sitzung. Wir führen einen loginPopup() Aufruf aus, rufen ein ID-Token ohne mehrstufige Authentifizierung ab. Anschließend wählt der Benutzer eine Schaltfläche aus, für die die App Daten von einer Web-API anfordern muss. Die App versucht, einen acquireTokenSilent() Aufruf auszuführen, schlägt jedoch fehl, da der Benutzer noch keine mehrstufige Authentifizierung ausgeführt hat und die Richtlinie für bedingten Zugriff einhalten muss.

Microsoft Entra ID sendet die folgende HTTP-Antwort zurück:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multifactor authentication to access '<Web API App/Client ID>'.

Die App muss error=interaction_required abfangen. Die Anwendung kann dann acquireTokenPopup() oder acquireTokenRedirect() für dieselbe Ressource verwenden. Der Benutzer wird gezwungen, eine mehrstufige Authentifizierung durchzuführen. Nachdem der Benutzer die mehrstufige Authentifizierung abgeschlossen hat, wird die App ein neues Zugriffstoken für die angeforderte Ressource ausgegeben.

Um dieses Szenario auszuprobieren, beachten Sie unser React SPA calling Node.js web API using on-behalf-of flow Code-Beispiel. Dieses Codebeispiel verwendet die Richtlinie für den bedingten Zugriff und die Web-API, die Sie zuvor mit einer React-SPA registriert haben, um dieses Szenario zu veranschaulichen. Es zeigt die ordnungsgemäße Behandlung der Anspruchanforderung und das Abrufen eines Zugriffstokens, das für Ihre Web-API verwendet werden kann.

Siehe auch

  • Last updated on