Entwicklerleitfaden für Microsoft Entra bedingten Zugriff

  • Artikel

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.

Dabei werden Kenntnisse über einzel- und mehrinstanzenfähige Apps sowie über allgemeine Authentifizierungsmuster 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 meisten Fällen hat der bedingte Zugriff keine Auswirkungen auf das Verhalten einer App und erfordert in der Regel auch keine Änderungen durch den 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. Dafür kann manchmal nur das Ausführen einer Anforderung für die interaktive Anmeldung erforderlich sein.

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

  • Apps für den „Im Auftrag von“-Ablauf
  • 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. Im Anschluss finden Sie einige Szenarien, in denen bedingter Zugriff für die mehrstufige Authentifizierung verwendet wird und die Aufschluss über den Unterschied geben.

  • 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. Der Benutzer muss eine Multi-Faktor-Authentifizierung (Multi-Factor Authentication, MFA) ausführen.
  • Sie erstellen eine native App, die einen Dienst der mittleren Ebene für den Zugriff auf eine Downstream-API verwendet. 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 den Richtlinien für den bedingten Zugriff die spezifischen Datasets zugeordnet sind, erzwingt Microsoft Entra ID die Richtlinien für den bedingten Zugriff auf der Grundlage der Daten die dem Diagramm zugrunde liegen, und nicht auf der Grundlage von Microsoft 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.

Einhalten einer Richtlinie für den 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, über eine Richtlinie für den bedingten Zugriff auf einen Dienst zuzugreifen, muss sie möglicherweise eine Anforderung für den bedingten Zugriff erfüllen. 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 speziellen Szenarien:

  • Apps für den „Im Auftrag von“-Ablauf
  • 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.

App performing the on-behalf-of flow diagram

Die anfängliche Tokenanforderung für die Web-API 1 fordert den Endbenutzer nicht zur Multi-Faktor-Authentifizierung auf, da die Web-API 1 nicht immer auf die Downstream-API zugreift. Wenn die Web-API 1 versucht, im Auftrag des Benutzers ein Token für die Web-API 2 anzufordern, führt diese Anforderung zu einem Fehler, da der Benutzer nicht mit der mehrstufigen Authentifizierung angemeldet ist.

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 multi-factor 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, und nachfolgende Anforderungen für den Webdienst A sind ebenfalls erfolgreich.

App accessing multiple-services flow diagram

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. Schwierig wird es, wenn die Anwendung anschließend ein Token für den Webdienst B anfordert. In diesem Fall muss der Endbenutzer die Richtlinie für den bedingten Zugriff erfüllen. 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 multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

App accessing multiple services requesting a new token

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 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().

Single-page app using MSAL flow diagram

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 Aufruf von loginPopup() durch und erhalten ohne Multi-Faktor-Authentifizierung ein ID-Token. 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 durchzuführen. Dieser führt jedoch zu einem Fehler, da der Benutzer keine Multi-Faktor-Authentifizierung durchgeführt hat, aber 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 multi-factor 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 muss eine Multi-Faktor-Authentifizierung durchführen. Nachdem der Benutzer die Multi-Faktor-Authentifizierung abgeschlossen hat, wird der App ein neues Zugriffstoken für die angeforderte Ressource ausgestellt.

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