Authentifizieren von .NET-Apps für Azure-Dienste mithilfe der Übersicht über die Azure Identity-Bibliothek

Wenn eine App auf eine Azure-Ressource zugreifen muss, muss die App bei Azure authentifiziert werden. Dies gilt für alle Apps, unabhängig davon, ob sie in Azure bereitgestellt, lokal oder in der Entwicklung auf einer lokalen Entwicklerarbeitsstation bereitgestellt werden. In diesem Artikel werden die empfohlenen Ansätze zum Authentifizieren einer App bei Azure bei Verwendung der Azure SDK-Clientbibliotheken beschrieben.

Empfohlener Ansatz für die App-Authentifizierung

Es wird empfohlen, dass Apps die tokenbasierte Authentifizierung anstelle von Verbindungszeichenfolgen beim Authentifizieren bei Azure-Ressourcen verwenden. Die Azure Identity-Bibliothek stellt Klassen bereit, die die tokenbasierte Authentifizierung unterstützen und apps die nahtlose Authentifizierung bei Azure-Ressourcen ermöglichen, unabhängig davon, ob sich die App in der lokalen Entwicklung befindet, in Azure bereitgestellt oder auf einem lokalen Server bereitgestellt wird.

Die spezifische Art der tokenbasierten Authentifizierung, die eine App für die Authentifizierung bei Azure-Ressourcen verwenden soll, hängt davon ab, wo die App ausgeführt wird und wie im folgenden Diagramm dargestellt 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 Azuregehostet, sollte sich die App mit einer verwalteten Identität bei Azure-Ressourcen authentifizieren. Diese Option wird unter Authentifizierung in Serverumgebungenausführlicher erläutert.
• Die App, die vor Ort gehostet und bereitgestellt wird, sollte sich mithilfe eines Anwendungsdienstprinzipal bei Azure-Ressourcen authentifizieren. Diese Option wird unter Authentifizierung in Serverumgebungenausführlicher erläutert.

DefaultAzureCredential

Die von der Azure Identity-Bibliothek bereitgestellte DefaultAzureCredential-Klasse ermöglicht Apps, je nach Umgebung, in der sie ausgeführt werden, unterschiedliche Authentifizierungsmethoden zu verwenden. Auf diese Weise können Apps von der lokalen Entwicklung zu Testumgebungen in die Produktion ohne Codeänderungen heraufgestuft werden. Sie konfigurieren die entsprechende Authentifizierungsmethode für jede Umgebung, und DefaultAzureCredential erkennt und verwendet diese Authentifizierungsmethode automatisch. Die Verwendung von DefaultAzureCredential sollte gegenüber der manuellen Codierung bedingter Logik oder Featurekennzeichnungen bevorzugt 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 einrichten, die von der App für die Azure-Ressource benötigt werden. 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.
• Bei einer verwalteten Identität ist kein Anwendungsgeheimnis zum Speichern vorhanden. Dadurch wird die App sicherer, da keine Verbindungszeichenfolge oder kein geheimer Anwendungsschlüssel vorhanden ist, der kompromittiert werden kann.
• Das Azure.Identity--Paket erwirbt und verwaltet Microsoft Entra-Token für Sie. Dies erleichtert die Verwendung der tokenbasierten Authentifizierung als Verbindungszeichenfolge.

Die Verwendung von Verbindungszeichenfolgen sollte auf anfängliche Machbarkeits-Apps oder Entwicklungsprototypen beschränkt sein, die nicht auf Produktionsdaten oder vertrauliche Daten zugreifen. Andernfalls sollten die tokenbasierten Authentifizierungsklassen, die in der Azure Identity-Bibliothek verfügbar sind, immer bevorzugt werden, wenn Sie sich bei Azure-Ressourcen authentifizieren.

Authentifizierung in Serverumgebungen

Beim Hosten in einer Serverumgebung sollte jeder App eine eindeutige Anwendungsidentität pro Umgebung zugewiesen werden, in der die App ausgeführt wird. In Azure wird eine Anwendungsidentität durch einen Dienstprinzipaldargestellt, ein spezieller Typ von Sicherheitsprinzipal, der apps für Azure identifizieren und authentifizieren soll. Der Dienstprinzipaltyp, der 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 und nur mit in Azure gehosteten Apps verwendet werden können. Beispielsweise würde eine .NET-Web-App, die in Azure App Service gehostet wird, einer verwalteten Identität zugewiesen. Die der App zugewiesene verwaltete Identität wird dann verwendet, um die App bei anderen Azure-Diensten zu authentifizieren. Erfahren Sie mehr über die Authentifizierung von von Azure gehosteten Apps
Apps, die außerhalb von Azure gehostet werden (z. B. lokale Apps)	Apps, die außerhalb von Azure gehostet werden (z. B. lokale Apps), die eine Verbindung mit Azure-Diensten herstellen müssen, sollten einen Anwendungsdienstprinzipalverwenden. Ein Anwendungsdienstprinzipal stellt die Identität der App in Azure dar und wird über den Anwendungsregistrierungsprozess erstellt. Betrachten Sie beispielsweise eine lokal gehostete .NET-Web-App, die Azure Blob Storage verwendet. Sie erstellen mithilfe des App-Registrierungsprozesses einen Anwendungsdienstprinzipal für die App. Die AZURE_CLIENT_ID, AZURE_TENANT_IDund AZURE_CLIENT_SECRET würden alle als Umgebungsvariablen gespeichert, die von der Anwendung zur Laufzeit gelesen werden sollen, und die App kann sich mit dem Anwendungsdienstprinzipal bei Azure authentifizieren. Erfahren Sie mehr über die Authentifizierung von Apps, die außerhalb von Azure gehostet werden.

Authentifizierung während der lokalen Entwicklung

Wenn eine App 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 für Azure während der lokalen Entwicklung sind:

Authentifizierungsmethode	Beschreibung
Erstellen von dedizierten Anwendungsdienstprinzipalobjekten, 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 als Umgebungsvariablen gespeichert, auf die die App zugreifen kann, wenn sie in der lokalen Entwicklung ausgeführt wird. Mit dieser Methode können Sie die spezifischen Ressourcenberechtigungen, die von der App benötigt werden, den Dienstprinzipalobjekten zuweisen, die von Entwicklern während der lokalen Entwicklung verwendet werden. Dadurch wird sichergestellt, dass die Anwendung nur Zugriff auf die benötigten Ressourcen hat und die Berechtigungen repliziert, die die App in der Produktion haben wird. Der Nachteil dieses Ansatzes ist die Notwendigkeit, separate Dienstprinzipalobjekte für jeden Entwickler zu erstellen, der an einer Anwendung arbeitet. Erfahren Sie mehr über die Authentifizierung von von Azure gehosteten Apps
Authentifizieren der App bei Azure mithilfe der Anmeldeinformationen des Entwicklers während der lokalen Entwicklung	Bei dieser Methode muss ein Entwickler über Visual Studio, die Azure Tools-Erweiterung für VS Code, die Azure CLI oder Azure PowerShell auf ihrer lokalen Arbeitsstation bei Azure angemeldet sein. Die Anwendung kann dann über den Anmeldeinformationsspeicher auf die Anmeldeinformationen des Entwicklers zugreifen und diese Anmeldeinformationen verwenden, um über die App auf Azure-Ressourcen zuzugreifen. Diese Methode hat den Vorteil der einfacheren Einrichtung, da sich ein Entwickler nur über Visual Studio, VS Code oder die Azure CLI bei ihrem Azure-Konto anmelden muss. Der Nachteil dieses Ansatzes besteht darin, dass das Konto des Entwicklers wahrscheinlich mehr Berechtigungen hat als für die Anwendung erforderlich. Daher repliziert dieser Ansatz nicht genau die Berechtigungen, mit denen die App in der Produktion ausgeführt wird. Erfahren Sie mehr über die Authentifizierung von von Azure gehosteten Apps

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 die Azure.Identity- und optional die Microsoft.Extensions.Azure-Pakete zu Ihrer Anwendung hinzu:

Befehlszeile

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

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

NuGet Package-Manager

Klicken Sie im Projektmappen-Explorer von Visual Studio im Fenster mit der rechten Maustaste auf Ihr Projekt, und wählen Sie NuGet-Pakete verwaltenaus. Suchen Sie nach Azure.Identity, und installieren Sie das entsprechende Paket. Wiederholen Sie diesen Vorgang für das Microsoft.Extensions.Azure-Paket.

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 über die Abhängigkeitsinjektion in ihrer gesamten App 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:

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:

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.

Wenn sie in Azure bereitgestellt werden, kann dieser Code Ihre App auch bei anderen Azure-Ressourcen authentifizieren. DefaultAzureCredential können Umgebungseinstellungen und verwaltete Identitätskonfigurationen abrufen, um sich automatisch bei anderen Diensten zu authentifizieren.