Konfigurieren Ihrer App Service- oder Azure Functions-App zur Verwendung der Microsoft Entra-Anmeldung

Wählen Sie einen anderen Authentifizierungsanbieter aus, um zu diesem zu springen.

Dieser Artikel zeigt Ihnen, wie Sie die Authentifizierung für Azure App Service oder Azure Functions so konfigurieren, dass Ihre App Benutzer und Benutzerinnen mit der Microsoft Identity Platform (Microsoft Entra) als Authentifizierungsanbieter anmeldet.

Auswählen eines Mandanten für Ihre Anwendung und deren Benutzer und Benutzerinnen

Bevor Ihre Anwendung Benutzer und Benutzerinnen anmelden kann, müssen Sie sie zuerst in einem Mitarbeitermandanten oder einem externen Mandanten registrieren. Wenn Sie Ihre App für Mitarbeiter- oder Geschäftsgäste verfügbar machen, registrieren Sie Ihre App in einem Mitarbeitermandanten. Wenn Ihre App für Consumer und Geschäftskunden bestimmt ist, registrieren Sie sie in einem externen Mandanten.

1. Melden Sie sich am Azure-Portal an und navigieren Sie zu Ihrer App.

2. Wählen Sie im linken Menü der App die Option Authentifizierung und anschließend Identitätsanbieter hinzufügen aus.

3. Wählen Sie auf der Seite Identitätsanbieter hinzufügen die Option Microsoft als Identitätsanbieter aus, um Microsoft- und Microsoft Entra ID-Identitäten anzumelden.

4. Wählen Sie für Mandantentyp die Option Konfiguration der Mitarbeiter (aktueller Mandant) für Mitarbeiter und Mitarbeiterinnen sowie Geschäftsgäste aus, oder wählen Sie Externe Konfiguration für Consumer und Geschäftskunden aus.

Auswählen der App-Registrierung

Das Feature „App Service-Authentifizierung“ kann automatisch eine App-Registrierung für Sie erstellen, oder Sie können eine Registrierung verwenden, die Sie oder ein Verzeichnisadministrator bzw. -administratorin separat erstellt haben.

Erstellen Sie automatisch eine neue App-Registrierung, es sei denn, Sie müssen eine App-Registrierung separat erstellen. Sie können die App-Registrierung im Microsoft Entra Admin Center später anpassen, wenn Sie möchten.

Die folgenden Situationen sind die häufigsten Fälle für die Verwendung einer vorhandenen App-Registrierung:

• Ihr Konto verfügt nicht über Berechtigungen zum Erstellen von App-Registrierungen in Ihrem Microsoft Entra-Mandanten.
• Sie möchten eine App-Registrierung von einem anderen Microsoft Entra-Mandanten verwenden als dem, in dem sich Ihre App befindet.
• Die Option zum Erstellen einer neuen Registrierung ist für Regierungs-Clouds nicht verfügbar.

Konfigurieren zusätzlicher Prüfungen

Konfigurieren Sie zusätzliche Prüfungen, um zu bestimmen, welche Anforderungen auf Ihre Anwendung zugreifen dürfen. Sie können dieses Verhalten jetzt anpassen oder diese Einstellungen später über den Hauptbildschirm der Authentifizierung anpassen, indem Sie neben den Authentifizierungseinstellungen die Option Bearbeiten auswählen.

Wählen Sie für Clientanwendungsanforderung Folgendes aus:

• Anforderungen nur von dieser Anwendung selbst zulassen
• Anforderungen von bestimmten Clientanwendungen zulassen
• Anforderungen nur jeder Anwendung zulassen (nicht empfohlen)

Wählen Sie für Identitätsanforderung Folgendes aus:

• Anforderungen von einer beliebigen Identität zulassen
• Anforderungen von bestimmten Identitäten zulassen

Wählen Sie für Mandantenanforderung Folgendes aus:

• Anforderungen nur vom Ausstellermandanten zulassen
• Anforderungen von bestimmten Mandanten zulassen
• Standardeinschränkungen basierend auf dem Aussteller verwenden

Ihre App muss möglicherweise noch weitere Autorisierungsentscheidungen im Code treffen. Weitere Informationen finden Sie unter Verwenden einer integrierten Autorisierungsrichtlinie.

Konfigurieren von Authentifizierungseinstellungen

Diese Optionen bestimmen, wie Ihre Anwendung auf nicht authentifizierte Anfragen reagiert, und die Standardeinstellungen leiten alle Anfragen zur Anmeldung mit diesem neuen Anbieter um. Sie können dieses Verhalten jetzt anpassen oder diese Einstellungen später über den Hauptbildschirm der Authentifizierung anpassen, indem Sie neben den Authentifizierungs-Einstellungendie Option Bearbeiten auswählen. Weitere Informationen zu diesen Optionen finden Sie unter Authentifizierungs-Fluss.

Entscheiden Sie für Zugriff einschränken, ob Sie folgende Einstellung aktivieren:

• Erzwingen Sie die Authentifizierung.
• Nicht authentifizierten Zugriff zulassen

Für Nicht authentifizierte Anforderungen

• HTTP 302 Gefundene Umleitung: für Websites empfohlen
• HTTP 401 Nicht autorisiert: für APIs empfohlen
• HTTP 403 – Unzulässig
• HTTP 404 Nicht gefunden

Wählen Sie Tokenspeicher aus (empfohlen). Der Tokenspeicher sammelt, speichert und aktualisiert Token für Ihre Anwendung. Sie können dies später deaktivieren, wenn Ihre App keine Token benötigt oder sie die Leistung optimieren müssen.

Hinzufügen des Identitätsanbieters

Wenn Sie die Mitarbeiterkonfiguration der Mitarbeiter ausgewählt haben, können Sie Weiter: Berechtigungen auswählen und alle Microsoft Graph-Berechtigungen hinzufügen, die von der Anwendung benötigt werden. Diese werden der APP-Registrierung hinzugefügt, Sie können Sie jedoch später auch ändern. Wenn Sie eine externe Konfiguration ausgewählt haben, können Sie später Microsoft Graph-Berechtigungen hinzufügen.

Wählen Sie Hinzufügen aus.

Sie sind nun bereit, die Microsoft Identity Platform für die Authentifizierung in Ihrer App zu verwenden. Der Anbieter wird auf dem Bildschirm Authentifizierung aufgeführt. Von dort aus können Sie diese Anbieterkonfiguration bearbeiten oder löschen.

Ein Beispiel für die Konfiguration der Microsoft Entra-Anmeldung für eine Web-App, die auf Azure Storage und Microsoft Graph zugreift, finden Sie in diesem Tutorial.

Autorisieren von Anforderungen

Standard mäßig verarbeitet die App Service-Authentifizierung nur die Authentifizierung, wobei bestimmt wird, ob der Aufrufer die Person ist, für die er sich ausgibt. Eine Autorisierung, die bestimmt, ob dieser Aufrufer Zugriff auf eine Ressource haben sollte, ist ein weiterer Schritt über die Authentifizierung hinaus. Weitere Informationen zu diesen Konzepten finden Sie unter Grundlagen der Microsoft Identity Platform-Autorisierung.

Ihre App kann Autorisierungsentscheidungen im Code treffen. App Service-Authentifizierung bietet einige integrierte Überprüfungen, die hilfreich sein können, aber möglicherweise alleine nicht ausreichen, um die Autorisierungsanforderungen Ihrer App zu erfüllen.

Durchführen von Überprüfungen im Anwendungscode

Wenn Sie Autorisierungsprüfungen in Ihrem App-Code durchführen, können Sie die Anspruchsinformationen verwenden, die die App Service-Authentifizierung zur Verfügung stellt. Der eingefügte x-ms-client-principal-Header enthält ein Base64-codiertes JSON-Objekt mit den Ansprüchen, die über den Aufrufer geltend gemacht werden. Standardmäßig durchlaufen diese Ansprüche eine Anspruchszuordnung, sodass die Anspruchsnamen möglicherweise nicht immer mit dem übereinstimmen, was im Token angezeigt wird. Der Anspruch tid wird beispielsweise stattdessen zu http://schemas.microsoft.com/identity/claims/tenantid zugeordnet.

Sie können auch direkt mit dem zugrunde liegenden Zugriffstoken aus dem eingefügten x-ms-token-aad-access-token-Header arbeiten.

Verwenden einer integrierten Autorisierungsrichtlinie

Die erstellte App-Registrierung authentifiziert eingehende Anforderungen für Ihren Microsoft Entra-Mandanten. Standardmäßig kann auch jeder innerhalb des Mandanten auf die Anwendung zugreifen, was für viele Anwendungen ausreichend ist. Einige Anwendungen müssen jedoch den Zugriff durch Autorisierungsentscheidungen weiter einschränken. Ihr Anwendungscode ist häufig der beste Ort, um benutzerdefinierte Autorisierungslogik zu verarbeiten. Für häufige Szenarien bietet die Microsoft-Identitätsplattform jedoch integrierte Überprüfungen, mit denen Sie den Zugriff einschränken können.

In diesem Abschnitt wird gezeigt, wie Sie integrierte Überprüfungen mithilfe der App Service-Authentifizierung V2-API aktivieren. Derzeit besteht die einzige Möglichkeit zur Konfiguration dieser integrierten Überprüfungen in der Verwendung von Azure Resource Manager-Vorlagen oder der REST-API.

Innerhalb des API-Objekts verfügt die Konfiguration des Microsoft Entra-Identitätsanbieters über einen Abschnitt validation, der ein defaultAuthorizationPolicy-Objekt wie in der folgenden Struktur enthalten kann:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}

Darüber hinaus können einige Überprüfungen unabhängig von der verwendeten API-Version über eine Anwendungseinstellung konfiguriert werden. Die Anwendungseinstellung WEBSITE_AUTH_AAD_ALLOWED_TENANTS kann mit einer durch Trennzeichen getrennten Liste von bis zu 10 Mandanten-IDs (z  B. „aaaabbbb-0000-cccc-1111-dddd2222eeee“) konfiguriert werden, um zu verlangen, dass das eingehende Token von einem der angegebenen Mandanten stammt, wie im tid-Anspruch angegeben. Die Anwendungseinstellung WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL kann auf „true“ oder „1“ konfiguriert werden, um zu verlangen, dass das eingehende Token einen oid-Anspruch enthält. Diese Einstellung wird ignoriert und als „true“ behandelt, wenn allowedPrincipals.identities konfiguriert wurde (da der oid-Anspruch gegen diese angegebene Liste von Identitäten überprüft wird).

Anforderungen, die diese integrierten Überprüfungen nicht bestehen, erhalten eine HTTP-Antwort 403 Forbidden.

Konfigurieren von Client-Apps für den Zugriff auf Ihre App Service-App

In den vorherigen Abschnitten haben Sie Ihren App Service oder Ihre Azure-Funktion registriert, um Benutzer zu authentifizieren. In diesem Abschnitt wird erläutert, wie Sie native Clients oder Daemon-Apps in Microsoft Entra registrieren können, damit diese im Namen von Benutzern oder im eigenen Namen Zugriff auf APIs beantragen können, die von Ihrer App Service-App zur Verfügung gestellt werden, beispielsweise in einer N-Schicht-Architektur. Sie müssen die in diesem Abschnitt beschriebenen Schritte nicht ausführen, wenn Sie nur Benutzer authentifizieren möchten.

Native Clientanwendung

Sie können native Clients registrieren, um im Namen eines angemeldeten Benutzers Zugriff auf die APIs Ihrer App Servic-App zu beantragen.

1. Wählen Sie im Menü des Portals Microsoft Entra aus.

2. Wählen Sie im linken Navigationsbereich App-Registrierungen>Neue Registrierung aus.

3. Geben Sie auf der Seite Anwendung registrieren einen Namen für Ihre App-Registrierung ein.

4. Wählen Sie unter Umleitungs-URI die Option Öffentlicher Client (Mobilgerät und Desktop) aus, und geben Sie die URL <app-url>/.auth/login/aad/callback ein. Beispiel: https://contoso.azurewebsites.net/.auth/login/aad/callback.

5. Wählen Sie Registrieren.

6. Sobald die App-Registrierung erstellt wurde, kopieren Sie den Wert von Anwendungs-ID (Client) .

   Hinweis

   Für eine Microsoft Store-Anwendung verwenden Sie stattdessen die Paket-SID als URI.

7. Wählen Sie im linken Navigationsbereich API-Berechtigungen>Berechtigung hinzufügen>Meine APIs aus.

8. Wählen Sie die App-Registrierung aus, die Sie zuvor für Ihre App Service-App erstellt haben. Wenn die App-Registrierung nicht angezeigt wird, stellen Sie sicher, dass Sie den Bereich user_impersonation in der App-Registrierung hinzugefügt haben.

9. Wählen Sie unter Delegierte Berechtigungen den Eintrag user_impersonation aus, und wählen Sie dann Berechtigungen hinzufügen aus.

Sie haben nun eine native Clientanwendung konfiguriert, die im Namen eines Benutzers Zugriff auf Ihre App Service-App beantragen kann.

Daemon-Clientanwendung (Dienst-zu-Dienst-Aufrufe)

In einer N-Schicht-Architektur kann Ihre Clientanwendung ein Token abrufen, um eine App Service- oder Funktions-App im Namen der Client-App selbst (nicht im Namen eines Benutzers) aufzurufen. Dieses Szenario ist nützlich für nicht interaktive Daemon-Anwendungen, die Aufgaben ohne angemeldeten Benutzer ausführen. Es verwendet die Standardzuweisung für Clientanmeldeinformationen von OAuth 2.0.

1. Wählen Sie im Menü des Portals Microsoft Entra aus.
2. Wählen Sie im linken Navigationsbereich App-Registrierungen>Neue Registrierung aus.
3. Geben Sie auf der Seite Anwendung registrieren einen Namen für Ihre App-Registrierung ein.
4. Für eine Daemon-Anwendung benötigen Sie keinen Umleitungs-URI, sodass Sie diesen Wert leer lassen können.
5. Wählen Sie Registrieren.
6. Sobald die App-Registrierung erstellt wurde, kopieren Sie den Wert von Anwendungs-ID (Client) .
7. Wählen Sie im linken Navigationsbereich Zertifikate und Geheimnisse>Geheime Clientschlüssel>Neuer geheimer Clientschlüssel aus.
8. Geben Sie eine Beschreibung und den Ablauf ein, und wählen Sie Hinzufügen aus.
9. Kopieren Sie im Feld Wert den Wert des geheimen Clientschlüssels. Er wird nicht mehr angezeigt, sobald Sie von dieser Seite weg navigieren.

Sie können jetzt ein Zugriffstoken mithilfe der Client-ID und des geheimen Clientschlüssels anfordern, indem Sie den Parameter resource auf den Anwendungs-ID-URI der Ziel-App festlegen. Das resultierende Zugriffstoken kann dann der Ziel-App mithilfe des standardmäßigen OAuth 2.0-Autorisierungsheaders angezeigt werden, woraufhin die App Service-Authentifizierung das Token überprüft und wie üblich verwendet, um jetzt anzuzeigen, dass der Aufrufer (in diesem Fall eine Anwendung, kein Benutzer) authentifiziert ist.

Im Moment ermöglicht dies jeder Clientanwendung in Ihrem Microsoft Entra-Mandanten, ein Zugriffstoken anzufordern und sich bei der Ziel-App zu authentifizieren. Wenn Sie außerdem bei der Autorisierung erzwingen möchten, dass nur bestimmte Clientanwendungen zugelassen werden, müssen Sie einige weitere Konfigurationen vornehmen.

1. Definieren Sie eine App-Rolle im Manifest der App-Registrierung, die die App Service- oder Funktions-App darstellt, die Sie schützen möchten.
2. Wählen Sie in der App-Registrierung, die den Client darstellt, der autorisiert werden muss, API-Berechtigungen>Berechtigung hinzufügen>Meine APIs aus.
3. Wählen Sie die App-Registrierung aus, die Sie zuvor erstellt haben. Wenn die App-Registrierung nicht angezeigt wird, stellen Sie sicher, dass Sie eine App-Rolle hinzugefügt haben.
4. Wählen Sie unter Anwendungsberechtigungen die zuvor erstellte App-Rolle aus, und wählen Sie dann Berechtigungen hinzufügen aus.
5. Wählen Sie unbedingt Administratoreinwilligung erteilen aus, um die Clientanwendung zum Anfordern der Berechtigung zu autorisieren.
6. Ähnlich wie im vorherigen Szenario (vor dem Hinzufügen jeglicher Rollen) können Sie jetzt ein Zugriffstoken anfordern für dieselbe Ziel-resource, woraufhin das Zugriffstoken einen roles-Anspruch aufnimmt, der die App-Rollen enthält, die für die Clientanwendung autorisiert wurden.
7. Im Code der App Service- oder Funktions-Ziel-App können Sie jetzt überprüfen, ob die erwarteten Rollen im Token vorhanden sind (dies wird nicht von der App Service-Authentifizierung durchgeführt). Weitere Informationen finden Sie unter Zugriff auf Benutzeransprüche.

Sie haben nun eine Daemon-Clientanwendung konfiguriert, die unter Verwendung der eigenen Identität auf Ihre App Service-App zugreifen kann.

Bewährte Methoden

Unabhängig von der Konfiguration, die Sie zum Einrichten der Authentifizierung verwenden, werden Ihnen die folgenden bewährten Methoden dabei helfen, Ihren Mandanten und Ihre Anwendungen besser zu schützen:

• Konfigurieren Sie jede App Service-App mit einer eigenen App-Registrierung in Microsoft Entra.
• Erteilen Sie jeder App Service-App eigene Berechtigungen und Einwilligung.
• Vermeiden Sie das Teilen von Berechtigungen zwischen Umgebungen, indem Sie separate App-Registrierungen für gesonderte Bereitstellungsslots verwenden. Wenn Sie neuen Code testen, kann diese Vorgehensweise dabei helfen, Probleme zu verhindern, die sich auf die Produktions-App auswirken können.

Migrieren zu Microsoft Graph

Einige ältere Apps wurden möglicherweise auch mit einer Abhängigkeit vom veralteten Azure AD Graph eingerichtet, das für die vollständige Außerbetriebnahme vorgesehen ist. Beispielsweise kann Ihr App-Code Azure AD-Graph aufgerufen haben, um die Gruppenmitgliedschaft als Teil eines Autorisierungsfilters in einer Middlewarepipeline zu überprüfen. Apps sollten zu Microsoft Graph wechseln, indem Sie die Anleitung befolgen, die von Microsoft Entra im Rahmen der Ausmusterung von Azure AD Graph bereitgestellt wird. Wenn Sie diese Anweisungen befolgen, müssen Sie möglicherweise einige Änderungen an Ihrer Konfiguration der App Service-Authentifizierung vornehmen. Nachdem Sie Ihrer App-Registrierung Microsoft Graph-Berechtigungen hinzugefügt haben, können Sie Folgendes ausführen:

1. Aktualisieren Sie die URL des Zertifikatausstellers so, dass sie das Suffix „/v2.0“ enthält, wenn dies noch nicht der Fall ist.

2. Entfernen Sie Anforderungen für Azure AD Graph-Berechtigungen aus Ihrer Anmeldekonfiguration. Die zu ändernden Eigenschaften hängen von der verwendeten Version der Verwaltungs-API ab:

   • Wenn Sie die V1-API (/authsettings) verwenden, befindet sie sich im additionalLoginParams-Array.
   • Wenn Sie die V2-API (/authsettingsV2) verwenden, befindet sie sich im loginParameters-Array.

   Sie müssen z. B. jeden Verweis auf https://graph.windows.net" entfernen. Dies umfasst den Parameter resource (der vom Endpunkt „/v2.0“ nicht unterstützt wird) oder alle Bereiche, die Sie speziell anfordern und die von Azure AD Graph stammen.

   Sie müssen auch die Konfiguration aktualisieren, um die neuen Microsoft Graph-Berechtigungen anzufordern, die Sie für die Anwendungsregistrierung eingerichtet haben. Sie können den .default-Bereich verwenden, um dieses Setup in vielen Fällen zu vereinfachen. Fügen Sie dafür einen neuen Anmeldeparameter scope=openid profile email https://graph.microsoft.com/.default hinzu.

Bei diesen Änderungen fordert die App Service-Authentifizierung keine Berechtigungen mehr für Azure AD Graph an, sondern erhält stattdessen ein Token für Microsoft Graph. Jede Verwendung dieses Tokens aus Ihrem Anwendungscode muss gemäß den von Microsoft Entra bereitgestellten Anleitungen ebenfalls aktualisiert werden.

Nächste Schritte

• Übersicht über die App Service-Authentifizierung/Autorisierung.
• Tutorial: Umfassendes Authentifizieren und Autorisieren von Benutzern in Azure App Service

• Tutorial: Hinzufügen der Authentifizierung zu Ihrer Web-App in Azure App Service
• Tutorial: Umfassendes Authentifizieren und Autorisieren von Benutzern in Azure App Service