Authentifizieren von .NET-Apps bei Azure-Diensten mithilfe des .NET Azure SDK

Wenn eine Anwendung auf eine Azure-Ressource wie Speicher, Schlüsseltresor oder Cognitive Services zugreifen muss, muss die Anwendung bei Azure authentifiziert werden. Dies gilt für alle Anwendungen, unabhängig davon, ob sie in Azure bereitgestellt, lokal bereitgestellt oder auf einer lokalen Entwicklerarbeitsstation entwickelt werden. In diesem Artikel werden die empfohlenen Ansätze zum Authentifizieren einer App bei Azure beschrieben, wenn Sie das Azure SDK für .NET verwenden.

Empfohlener App-Authentifizierungsansatz

Apps sollten bei der Authentifizierung bei Azure-Ressourcen die tokenbasierte Authentifizierung anstelle von Verbindungszeichenfolgen verwenden. Das Azure SDK for .NET bietet Klassen, die tokenbasierte Authentifizierung unterstützen und Apps ermöglichen, sich nahtlos bei Azure-Ressourcen zu authentifizieren, unabhängig davon, ob sich die App in der lokalen Entwicklung befindet, in Azure bereitgestellt oder auf einem lokalen Server bereitgestellt wird.

Welchen spezifischen Typ der tokenbasierten Authentifizierung eine App für die Authentifizierung bei Azure-Ressourcen verwenden sollte, hängt davon ab, wo die App ausgeführt wird, und wird im folgenden Diagramm dargestellt.

• Wenn ein Entwickler während der lokalen Entwicklung eine App ausführt: Die App kann sich entweder mit einem Anwendungsdienstprinzipal für die lokale Entwicklung oder mithilfe der Azure-Anmeldeinformationen des Entwicklers bei Azure authentifizieren. Jede dieser Optionen wird im Abschnitt Authentifizierung während der lokalen Entwicklung ausführlicher erläutert.
• Wenn eine App in Azure gehostet wird: Die App sollte sich mit einer verwalteten Identität bei Azure-Ressourcen authentifizieren. Diese Option wird weiter unten im Abschnitt Authentifizierung in Serverumgebungen ausführlicher erläutert.
• Wenn eine App lokal gehostet und bereitgestellt wird: Die App sollte sich mithilfe eines Anwendungsdienstprinzipals bei Azure-Ressourcen authentifizieren. Diese Option wird weiter unten im Abschnitt Authentifizierung in Serverumgebungen ausführlicher erläutert.

DefaultAzureCredential

Die vom Azure SDK bereitgestellte DefaultAzureCredential-Klasse ermöglicht Apps, je nach der Umgebung, in der sie ausgeführt werden, verschiedene Authentifizierungsmethoden zu verwenden. 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 der DefaultAzureCredential-Klasse werden weiter unten in diesem Artikel im Abschnitt Verwenden von DefaultAzureCredential in einer Anwendung behandelt.

Vorteile der tokenbasierten Authentifizierung

Beim Erstellen von Apps für Azure sollte unbedingt die tokenbasierte Authentifizierung anstelle von Verbindungszeichenfolgen verwendet werden. 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. Hier gilt das Prinzip der geringsten Rechte. Im Gegensatz dazu gewährt eine Verbindungszeichenfolge vollständige Rechte für die Azure-Ressource.
• Während jede Person oder jede App mit einer Verbindungszeichenfolge eine Verbindung mit einer Azure-Ressource herstellen kann, beschränken tokenbasierte Authentifizierungsmethoden den Ressourcenzugriff auf die Apps, die für den Zugriff auf die Ressource vorgesehen sind.
• Im Fall einer verwalteten Identität muss kein Anwendungsgeheimnis gespeichert werden. Dies macht die App sicherer, da weder eine Verbindungszeichenfolge noch ein Anwendungsgeheimnis vorhanden ist, die/das kompromittiert werden kann.
• Das Azure.Identity-Paket im Azure SDK verwaltet Token für Sie im Hintergrund. 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. In allen anderen Fällen sollten Sie immer die tokenbasierten Authentifizierungsklassen, die im Azure SDK verfügbar sind, für die Authentifizierung bei Azure-Ressourcen verwenden.

Authentifizierung in Serverumgebungen

Beim Hosten in einer Serverumgebung sollte jeder Anwendung eine eindeutige Anwendungsidentität pro Umgebung zugewiesen werden, in der die Anwendung ausgeführt wird. In Azure wird eine App-Identität durch einen Dienstprinzipal dargestellt, einen speziellen Typ von Sicherheitsprinzipal, der zum Identifizieren und Authentifizieren von Apps bei Azure bestimmt ist. 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. Erfahren Sie mehr über die Authentifizierung aus in Azure gehosteten Apps.
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. Erfahren Sie mehr über die 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. Erfahren Sie mehr über die Authentifizierung aus in Azure gehosteten Apps.
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. Erfahren Sie mehr über die Authentifizierung aus in Azure gehosteten Apps.

Verwenden von DefaultAzureCredential in einer Anwendung

DefaultAzureCredential unterstützt mehrere Authentifizierungsmethoden und bestimmt die zur Laufzeit verwendete Authentifizierungsmethode. Auf diese Weise kann Ihre App verschiedene Authentifizierungsmethoden in verschiedenen Umgebungen verwenden, ohne umgebungsspezifischen Code zu implementieren.

Die Reihenfolge und die Speicherorte, in denen nach Anmeldeinformationen gesucht wird, DefaultAzureCredential finden Sie unter DefaultAzureCredential.

Um zu implementieren DefaultAzureCredential, fügen Sie zuerst die Azure.Identity Pakete und optional zu Microsoft.Extensions.Azure Ihrer Anwendung hinzu. Dazu können Sie entweder die Befehlszeile oder den NuGet-Paket-Manager verwenden.

Befehlszeile

Öffnen Sie eine Terminalumgebung Ihrer Wahl im Anwendungsprojektverzeichnis, und geben Sie den folgenden Befehl ein.

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

NuGet-Paket-Manager

Klicken Sie in Visual Studio mit der rechten Maustaste auf Ihren Projektknoten, und wählen Sie NuGet-Pakete verwalten aus. Suchen Sie im Suchfeld nach Azure.Identity, und installieren Sie das entsprechende Paket. Wiederholen Sie diesen Vorgang auch für das Microsoft.Extensions.Azure-Paket.

Auf Azure-Dienste wird im Allgemeinen über entsprechende Clientklassen aus dem SDK zugegriffen. Diese Klassen und Ihre eigenen benutzerdefinierten Dienste sollten in der Datei Program.cs registriert werden, damit über die Abhängigkeitsinjektion in der gesamten App darauf zugegriffen werden kann. Führen Sie innerhalb von Program.cs die folgenden Schritte aus, um Ihren Dienst und DefaultAzureCredential ordnungsgemäß einzurichten.

1. Schließen Sie die Azure.Identity Namespaces und Microsoft.Extensions.Azure in eine using-Anweisung ein.
2. Registrieren Sie den Azure-Dienst mithilfe relevanter Hilfsmethoden.
3. Übergeben Sie eine Instanz des DefaultAzureCredential-Objekts an die UseCredential-Methode.

Ein Beispiel dafür wird im folgenden Codeausschnitt gezeigt.

using Microsoft.Extensions.Azure;
using Azure.Identity;

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

Alternativ können Sie ihre Dienste auch direkter nutzen DefaultAzureCredential , ohne zusätzliche Azure-Registrierungsmethoden zu verwenden, wie unten zu sehen.

using Azure.Identity;

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

Wenn der obige Code während der lokalen Entwicklung auf Ihrer lokalen Arbeitsstation ausgeführt wird, sucht er in den Umgebungsvariablen nach einem Anwendungsdienstprinzipal oder in Visual Studio, VS Code, der Azure CLI oder Azure PowerShell nach einer Reihe von Entwickleranmeldeinformationen, von denen beide zur Authentifizierung der App bei Azure-Ressourcen während der lokalen Entwicklung verwendet werden können.

Bei der Bereitstellung in Azure kann dieser Code Ihre App 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.

Untersuchen der Sequenz der DefaultAzureCredential-Authentifizierungsmethoden

DefaultAzureCredential implementiert intern eine Kette von Anmeldeinformationsanbietern für die Authentifizierung von Anwendungen bei Azure-Ressourcen. Jeder Anmeldeinformationsanbieter kann erkennen, ob Anmeldeinformationen dieses Typs für die App konfiguriert sind. DefaultAzureCredential überprüft der Reihe nach jeden Anbieter und verwendet die Anmeldeinformationen des ersten Anbieters, der Anmeldeinformationen konfiguriert hat.

Die Reihenfolge und die Speicherorte, in denen nach Anmeldeinformationen gesucht wird, DefaultAzureCredential finden Sie unter DefaultAzureCredential.

Anmeldeinformationstyp	BESCHREIBUNG
Anwendungs-Dienstprinzipal	DefaultAzureCredential liest eine Reihe von Umgebungsvariablen, um zu ermitteln, ob ein Anwendungsdienstprinzipal (Anwendungsbenutzer) für die App festgelegt wurde. Wenn ja, verwendet DefaultAzureCredential diese Werte, um die App bei Azure zu authentifizieren. Diese Methode wird am häufigsten in Serverumgebungen verwendet, kann aber auch bei der lokalen Entwicklung verwendet werden.
Verwaltete Identität	Wenn die Anwendung auf einem Azure-Host mit aktivierter verwalteter Identität bereitgestellt wird, authentifiziert DefaultAzureCredential die App mit dieser verwalteten Identität bei Azure. Die Authentifizierung mithilfe einer verwalteten Identität wird im Abschnitt Authentifizierung in Serverumgebungen dieses Dokuments erläutert. Diese Methode ist nur verfügbar, wenn eine Anwendung mit einem Dienst wie Azure App Service, Azure Functions oder Azure Virtual Machines in Azure gehostet wird.
Visual Studio	Wenn sich der Entwickler bei Azure authentifiziert hat, indem er sich bei Visual Studio angemeldet hat, authentifiziert DefaultAzureCredential die App mit demselben Konto bei Azure.
Visual Studio Code	Wenn sich der Entwickler mit dem Visual Studio Code-Azure-Konto-Plug-In bei Azure authentifiziert hat, authentifiziert DefaultAzureCredential die App mit demselben Konto bei Azure.
Azure CLI	Wenn sich ein Entwickler mit dem az login-Befehl in der Azure CLI bei Azure authentifiziert hat, authentifiziert DefaultAzureCredential die App mit demselben Konto bei Azure.
Azure PowerShell	Wenn sich ein Entwickler mit dem Connect-AzAccount-Cmdlet von Azure PowerShell bei Azure authentifiziert hat, authentifiziert DefaultAzureCredential die App mit demselben Konto bei Azure.
Interactive	Wenn aktiviert, authentifiziert DefaultAzureCredential den Entwickler interaktiv über den Standardbrowser des aktuellen Systems. Diese Option ist standardmäßig deaktiviert.