Auf Englisch lesen

Freigeben über

Authentifizieren von .NET-Anwendungen bein Azure-Diensten mithilfe der Übersicht über die Azure Identity-Bibliothek

  • Artikel

Wenn eine Anwendung auf eine Azure-Ressource zugreifen muss, muss diese bei Azure authentifiziert werden. Diese Anforderung gilt für alle Anwendungen, unabhängig davon, ob sie in Azure oder lokal bereitgestellt werden oder sich in der Entwicklung auf einer lokalen Entwicklerarbeitsstation befinden. In diesem Artikel werden die empfohlenen Vorgehensweisen für die Authentifizierung einer Anwendung bei Azure beschrieben, wenn Sie das Azure SDK für Python verwenden.

Es wird empfohlen, Anwendungen bei Azure-Ressourcen über die tokenbasierte Authentifizierung und nicht über Verbindungszeichenfolgen zu authentifizieren. Die Azure Identity-Clientbibliothek stellt Klassen bereit, die die tokenbasierte Authentifizierung unterstützen und Anwendungen eine nahtlose Authentifizierung bei Azure-Ressourcen ermöglichen, unabhängig davon, ob sich diese in der lokalen Entwicklung, in Azure oder auf einem lokalen Server befinden.

Eine Anwendung, die sich bei Azure-Ressourcen authentifizieren soll, sollte, je nachdem, wo sie ausgeführt wird, eine bestimmte Art der tokenbasierten Authentifizierung verwenden. Dies ist im folgenden Diagramm dargestellt:

Ein Diagramm, das die empfohlenen tokenbasierten Authentifizierungsstrategien für eine App zeigt, je nachdem, wo sie ausgeführt wird.

Wenn eine App Folgendes tut:

  • Die App wird während der Entwicklung lokal ausgeführt und kann sich bei Azure entweder mit einem Anwendungsdienstprinzipal für die lokale Entwicklung oder mit den Azure-Anmeldedaten des Entwicklers authentifizieren. Jede Option wird ausführlicher unter Authentifizierung während der lokalen Entwicklungerläutert.
  • In Azure gehostet: Die Anwendung sollte sich bei Azure-Ressourcen mit einer verwalteten Identität authentifizieren. Diese Option wird in Abschnitt Authentifizierung in Serverumgebungen ausführlicher erläutert.
  • Die App, die vor Ort gehostet und bereitgestellt wird, sollte sich mithilfe eines Anwendungsdienstprinzipal bei Azure-Ressourcen authentifizieren. Diese Option wird in Abschnitt Authentifizierung in Serverumgebungen ausführlicher erläutert.

DefaultAzureCredential

Die von der Azure Identity-Bibliothek bereitgestellte Klasse DefaultAzureCredential ermöglicht Anwendungen die Verwendung unterschiedlicher Authentifizierungsverfahren, je nach der Umgebung, in der sie ausgeführt werden. So können Apps ohne Codeänderungen von der lokalen Entwicklung über Testumgebungen bis hin zur Produktion heraufgestuft werden. Sie konfigurieren die geeignete Authentifizierungsmethode für jede Umgebung, und DefaultAzureCredential erkennt und verwendet diese Authentifizierungsmethode automatisch. Die Verwendung von DefaultAzureCredential sollte der manuellen Codierung bedingter Logik oder Featureflags vorgezogen werden, um unterschiedliche Authentifizierungsmethoden in verschiedenen Umgebungen zu verwenden.

Details zur Verwendung von DefaultAzureCredential werden behandelt unter Verwendung von DefaultAzureCredential in einer Anwendung.

Vorteile der tokenbasierten Authentifizierung

Die tokenbasierte Authentifizierung bietet die folgenden Vorteile gegenüber der Authentifizierung mit Verbindungszeichenfolgen:

  • Mit den unten beschriebenen tokenbasierten Authentifizierungsmethoden können Sie die spezifischen Berechtigungen festlegen, die die App für die Azure-Ressource benötigt. Dies folgt dem Prinzip des geringsten Privilegs. Im Gegensatz dazu gewährt eine Verbindungszeichenfolge vollständige Rechte für die Azure-Ressource.
  • Während jede oder jede App mit einer Verbindungszeichenfolge eine Verbindung mit einer Azure-Ressource herstellen kann, beschränken token-basierte Authentifizierungsmethoden den Zugriff auf die Ressource auf nur die App(s), die für den Zugriff vorgesehen sind.
  • Im Falle einer verwalteten Identität muss kein Anwendungsgeheimnis gespeichert werden. Dadurch ist die Anwendung sicherer, da es keine Verbindungszeichenfolge oder kein Anwendungsgeheimnis gibt, die bzw. das kompromittiert werden kann.
  • Das Azure.Identity-Paket erwirbt und verwaltet Microsoft Entra-Token für Sie. So kann die tokenbasierte Authentifizierung so einfach wie eine Verbindungszeichenfolge verwendet werden.

Die Verwendung von Verbindungszeichenfolgen sollte auf erste Proof-of-Concept-Apps oder Entwicklungsprototypen beschränkt werden, die nicht auf Produktionsdaten oder vertrauliche Daten zugreifen. Andernfalls sollten bei der Authentifizierung bei Azure-Ressourcen immer die tokenbasierten Authentifizierungsklassen bevorzugt, die in der Azure Identity-Bibliothek verfügbar sind.

Authentifizierung in Serverumgebungen

Beim Hosten in einer Serverumgebung sollte jeder Anwendung eine eindeutige Anwendungsidentität pro Umgebung zugewiesen werden, in der die App ausgeführt wird. In Azure wird eine Anwendungsidentität durch einen Dienstprinzipal dargestellt, ein spezieller Typ des Sicherheitsprinzipals, der Anwendungen bei Azure identifiziert und authentifiziert. Welcher Dienstprinzipaltyp für Ihre App verwendet werden soll, hängt davon ab, wo Ihre App ausgeführt wird.

Authentifizierungsmethode Beschreibung
In Azure gehostete Apps In Azure gehostete Apps sollten einen Dienstprinzipal für verwaltete Identitäten verwenden. Verwaltete Identitäten sind so konzipiert, dass sie die Identität einer in Azure gehosteten App darstellen. Sie können nur bei von Azure gehosteten Apps verwendet werden.

Beispielsweise wird einer in Azure App Service gehosteten .NET-Web-App eine verwaltete Identität zugewiesen. Dann wird die der App zugewiesene verwaltete Identität verwendet, um die App bei anderen Azure-Diensten zu authentifizieren.

Informationen zur Authentifizierung Apps, die in Azure gehostet werden
Außerhalb von Azure gehostete Apps
(z. B. lokale Apps)		 Apps, die außerhalb von Azure gehostet werden (z. B. lokale Apps) und eine Verbindung mit Azure-Diensten herstellen müssen, sollten einen Anwendungsdienstprinzipal verwenden. Ein Anwendungsdienstprinzipal stellt die Identität der App in Azure dar und wird über den App-Registrierungsprozess erstellt.

Betrachten Sie beispielsweise eine lokal gehostete .NET-Web-App, die Azure Blob Storage nutzt. Sie erstellen mithilfe des App-Registrierungsprozesses einen Anwendungsdienstprinzipal für die App. Die Werte AZURE_CLIENT_ID, AZURE_TENANT_ID und AZURE_CLIENT_SECRET werden alle als Umgebungsvariablen gespeichert, die von der Anwendung zur Laufzeit gelesen werden sollen und der App die Authentifizierung bei Azure mithilfe des Anwendungsdienstprinzipals ermöglichen.

Informationen zur Authentifizierung von Apps, die außerhalb von Azure gehostet werden

Authentifizierung während der lokalen Entwicklung

Wenn eine Anwendung während der lokalen Entwicklung auf der Arbeitsstation eines Entwicklers ausgeführt wird, muss sie sich weiterhin bei allen von der App verwendeten Azure-Diensten authentifizieren. Die beiden wichtigsten Strategien für die Authentifizierung von Apps bei Azure während der lokalen Entwicklung sind:

Authentifizierungsmethode Beschreibung
Erstellen dedizierter Anwendungsdienstprinzipal-Objekte, die während der lokalen Entwicklung verwendet werden sollen Bei dieser Methode werden dedizierte Anwendungsdienstprinzipalobjekte mithilfe des App-Registrierungsprozesses zur Verwendung während der lokalen Entwicklung eingerichtet. Die Identität des Dienstprinzipals wird dann in Form von Umgebungsvariablen gespeichert, auf die die App zugreifen kann, wenn sie in der lokalen Entwicklung ausgeführt wird.

Mithilfe dieser Methode können Sie den Dienstprinzipalobjekten, die von Entwicklern während der lokalen Entwicklung verwendet werden, die von der App benötigten spezifischen Ressourcenberechtigungen zuweisen. Dieser Ansatz stellt sicher, dass die Anwendung nur Zugriff auf die von ihr benötigten spezifischen Ressourcen hat, und er repliziert die Berechtigungen, die die App in einer Produktionsumgebung haben wird.

Der Nachteil bei diesem Ansatz besteht darin, dass für jeden Entwickler, der an einer Anwendung arbeitet, separate Dienstprinzipalobjekte erstellt werden müssen.

Informationen zur Authentifizierung Apps, die in Azure gehostet werden
Authentifizieren der App bei Azure mithilfe der Anmeldeinformationen des Entwicklers während der lokalen Entwicklung Bei dieser Methode müssen Entwickler und Entwicklerinnen über Visual Studio, die Azure Tools-Erweiterung für VS Code, die Azure-Befehlszeilenschnittstelle oder Azure PowerShell auf ihrer lokalen Arbeitsstation bei Azure angemeldet sein. Die Anwendung kann dann über den Anmeldeinformationsspeicher auf die Anmeldeinformationen der Entwickler oder Entwicklerinnen zugreifen und sie dazu verwenden, um aus der App auf Azure-Ressourcen zuzugreifen.

Diese Methode hat den Vorteil einer einfacheren Einrichtung, da sich die Entwickler und Entwicklerinnen nur über Visual Studio, VS Code oder die Azure-Befehlszeilenschnittstelle bei ihrem Azure-Konto anmelden müssen. Der Nachteil bei diesem Ansatz: Das Konto des Entwicklers hat wahrscheinlich mehr Berechtigungen, als von der Anwendung benötigt werden. Daher werden bei diesem Ansatz die Berechtigungen, mit denen die App in der Produktion ausgeführt wird, nicht genau repliziert.

Informationen zur Authentifizierung Apps, die in Azure gehostet werden

Verwenden von DefaultAzureCredential in einer Anwendung

DefaultAzureCredential ist eine strikte und geordnete Abfolge von Mechanismen zur Authentifizierung für Microsoft Entra ID. Jeder Authentifizierungsmechanismus ist eine von der Klasse TokenCredential abgeleitete Klasse und wird als Anmeldeinformation bezeichnet. Zur Laufzeit versucht DefaultAzureCredential, sich mit den ersten Anmeldeinformationen zu authentifizieren. Wenn mit dieser Anmeldeinformation kein Zugriffstoken abgerufen werden kann, wird die nächste Anmeldeinformation in der Folge ausprobiert, bis ein Zugriffstoken erfolgreich abgerufen wird. Auf diese Weise kann Ihre App unterschiedliche Anmeldeinformationen in verschiedenen Umgebungen verwenden, ohne umgebungsspezifischen Code zu schreiben.

Um DefaultAzureCredentialzu verwenden, fügen Sie Ihrer Anwendung das Paket Azure.Identity und optional das Paket Microsoft.Extensions.Azure hinzu:

Navigieren Sie in einem Terminal Ihrer Wahl zum Anwendungsprojektverzeichnis, und führen Sie die folgenden Befehle aus:

.NET CLI 
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure

Auf Azure-Dienste wird mithilfe spezieller Clientklassen aus den verschiedenen Azure SDK-Clientbibliotheken zugegriffen. Diese Klassen und Ihre eigenen benutzerdefinierten Dienste sollten registriert werden, damit sie in Ihrer gesamten App über die Abhängigkeitsinjektion aufgerufen werden können. Führen Sie in Program.cs die folgenden Schritte durch, um eine Clientklasse und DefaultAzureCredential zu registrieren:

  1. Schließen Sie die Namespaces Azure.Identity und Microsoft.Extensions.Azure mittels der using-Direktiven ein.
  2. Registrieren Sie den Azure-Dienstclient mit der entsprechenden Add-Präfix-Erweiterungsmethode.
  3. Übergeben Sie eine Instanz von DefaultAzureCredential an die UseCredential-Methode.

Zum Beispiel:

c# 
using Microsoft.Extensions.Azure;
using Azure.Identity;

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));
    clientBuilder.UseCredential(new DefaultAzureCredential());
});

Eine Alternative zu UseCredential besteht darin, DefaultAzureCredential direkt zu instanziieren:

c# 
using Azure.Identity;

builder.Services.AddSingleton<BlobServiceClient>(_ =>
    new BlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"),
        new DefaultAzureCredential()));

Wenn der vorherige Code auf Ihrer lokalen Entwicklungsarbeitsstation ausgeführt wird, sucht er in den Umgebungsvariablen nach einem Dienstprinzipal für Anwendungen oder in lokal installierten Entwicklertools wie Visual Studio nach Entwickleranmeldeinformationen. Beide Ansätze können verwendet werden, um die App während der lokalen Entwicklung bei Azure-Ressourcen zu authentifizieren.

Bei der Bereitstellung in Azure kann dieser Code Ihre Anwendung auch bei anderen Azure-Ressourcen authentifizieren. DefaultAzureCredential kann Umgebungseinstellungen und Konfigurationen für verwaltete Identitäten abrufen, um sich automatisch bei anderen Diensten zu authentifizieren.