Freigeben über

Bewährte Methoden für die Authentifizierung mit der Azure Identity-Bibliothek für .NET

Dieser Artikel enthält Richtlinien, die Ihnen helfen, die Leistung und Zuverlässigkeit Ihrer .NET-Apps beim Authentifizieren bei Azure-Diensten zu maximieren. Um die Azure Identity-Bibliothek für .NET optimal zu nutzen, ist es wichtig, potenzielle Probleme und Gegenmaßnahmen zu verstehen.

Verwenden von deterministischen Anmeldeinformationen in Produktionsumgebungen

DefaultAzureCredential ist die lösungsfähigste Methode, um mit der Azure Identity-Bibliothek zu beginnen, aber dieser Komfort führt auch bestimmte Kompromisse ein. Vor allem die spezifischen Anmeldeinformationen in der Kette, die erfolgreich sind und für die Anforderungsauthentifizierung verwendet werden, können vorab nicht garantiert werden. In einer Produktionsumgebung kann diese Unvorstellbarkeit erhebliche und manchmal subtile Probleme verursachen.

Betrachten Sie beispielsweise die folgende hypothetische Abfolge von Ereignissen:

  1. Das Sicherheitsteam einer Organisation schreibt vor, dass alle Apps eine verwaltete Identität verwenden, um sich bei Azure-Ressourcen zu authentifizieren.
  2. Monate lang verwendet eine .NET-App, die auf einem virtuellen Azure-Computer (VM) gehostet wird, DefaultAzureCredential zur Authentifizierung über verwaltete Identitäten.
  3. Ohne dem Supportteam mitzuteilen, installiert ein Entwickler die Azure CLI auf diesem virtuellen Computer und führt den befehl az login aus, um sich bei Azure zu authentifizieren.
  4. Aufgrund einer separaten Konfigurationsänderung in der Azure-Umgebung beginnt die Authentifizierung über die ursprüngliche verwaltete Identität unerwartet unbemerkt zu scheitern.
  5. DefaultAzureCredential überspringt die fehlgeschlagene ManagedIdentityCredential und sucht nach der nächsten verfügbaren Anmeldeinformation, die AzureCliCredential ist.
  6. Die Anwendung beginnt mit der Verwendung der Azure CLI-Anmeldeinformationen anstelle der verwalteten Identität, was möglicherweise fehlschlägt oder zu unerwarteten Erhöhungen und Reduzierungen von Berechtigungen führen kann.

Um diese Arten von subtilen Problemen oder stillen Fehlern in Produktionsanwendungen zu verhindern, ersetzen Sie DefaultAzureCredential durch eine spezifische TokenCredential Implementierung, z. B. ManagedIdentityCredential. Die Optionen finden Sie in der Liste Abgeleitet.

Betrachten Sie beispielsweise die folgende Konfiguration in einem ASP.NET Core-Projekt. Eine Instanz von DefaultAzureCredential wird implizit erstellt und für alle registrierten Dienstclients verwendet:

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(
        new Uri($"https://{keyVaultName}.vault.azure.net"));
    clientBuilder.AddBlobServiceClient(
        new Uri($"https://{storageAccountName}.blob.core.windows.net"));
});

Ändern Sie den vorherigen Code, um basierend auf der Umgebung, in der die App ausgeführt wird, anmeldeinformationen auszuwählen:

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(
        new Uri($"https://{keyVaultName}.vault.azure.net"));
    clientBuilder.AddBlobServiceClient(
        new Uri($"https://{storageAccountName}.blob.core.windows.net"));

    TokenCredential credential;

    if (builder.Environment.IsProduction() || builder.Environment.IsStaging())
    {
        string? clientId = builder.Configuration["UserAssignedClientId"];
        credential = new ManagedIdentityCredential(
            ManagedIdentityId.FromUserAssignedClientId(clientId));
    }
    else
    {
        // local development environment
        credential = new ChainedTokenCredential(
            new VisualStudioCredential(),
            new AzureCliCredential(),
            new AzurePowerShellCredential());
    }

    clientBuilder.UseCredential(credential);
});

In diesem Beispiel wird nur ManagedIdentityCredential in der Produktion verwendet. Die Authentifizierungsanforderungen der lokalen Entwicklungsumgebung werden dann durch die Sequenz von Anmeldeinformationen, die in der else Klausel definiert sind, gewartet.

Wiederverwendung von Zugangsdateninstanzen

Verwenden Sie nach Möglichkeit Authentifizierungsinstanzen, um die Resilienz der App zu verbessern und die Anzahl der Zugriffstokenanforderungen zu verringern, die an Microsoft Entra ID ausgegeben werden. Wenn eine Anmeldeinformation wiederverwendet wird, wird versucht, ein Token aus dem App-Tokencache abzurufen, der von der zugrunde liegenden MSAL-Abhängigkeit verwaltet wird. Weitere Informationen finden Sie unter Token-Caching in der Azure Identity-Clientbibliothek.

Wichtig

Eine App mit hohem Volumen, die keine Anmeldeinformationen wiederverwendet, kann auf HTTP 429-Drosselungsantworten von Microsoft Entra-ID stoßen, was zu App-Ausfällen führen kann.

Die empfohlene Wiederverwendungsstrategie für Anmeldeinformationen unterscheidet sich von .NET-Anwendungstyp.

Um die Wiederverwendung von Anmeldeinformationen zu implementieren, verwenden Sie die UseCredential Methode von Microsoft.Extensions.Azure. Erwägen Sie eine ASP.NET Core-App, die in Azure App Service in Produktions- und Stagingumgebungen gehostet wird. Die Umgebungsvariable ASPNETCORE_ENVIRONMENT wird entweder auf Production oder Staging festgelegt, um zwischen diesen beiden Nicht-Entwicklungsumgebungen zu unterscheiden. Sowohl in der Produktion als auch im Staging wird die vom Benutzer zugewiesene Variante ManagedIdentityCredential verwendet, um die Key Vault Secrets- und Blob Storage-Clients zu authentifizieren.

Wenn die App auf einem lokalen Entwicklungscomputer ausgeführt wird und ASPNETCORE_ENVIRONMENT auf Development festgelegt ist, wird stattdessen eine verkettete Folge von Anmeldeinformationen für Entwicklerwerkzeuge verwendet. Mit diesem Ansatz wird sichergestellt, dass umgebungsgerechte Anmeldeinformationen verwendet, die Sicherheit verbessert und die Verwaltung von Anmeldeinformationen vereinfacht wird.

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(
        new Uri($"https://{keyVaultName}.vault.azure.net"));
    clientBuilder.AddBlobServiceClient(
        new Uri($"https://{storageAccountName}.blob.core.windows.net"));

    TokenCredential credential;

    if (builder.Environment.IsProduction() || builder.Environment.IsStaging())
    {
        string? clientId = builder.Configuration["UserAssignedClientId"];
        credential = new ManagedIdentityCredential(
            ManagedIdentityId.FromUserAssignedClientId(clientId));
    }
    else
    {
        // local development environment
        credential = new ChainedTokenCredential(
            new VisualStudioCredential(),
            new AzureCliCredential(),
            new AzurePowerShellCredential());
    }

    clientBuilder.UseCredential(credential);
});

Informationen zu diesem Ansatz in einer ASP.NET Core-App finden Sie unter Authentifizieren mithilfe von Microsoft Entra ID.

Verstehen, wann Tokenlebensdauer und Zwischenspeicherungslogik erforderlich sind

Wenn Sie Anmeldeinformationen der Azure Identity-Bibliothek außerhalb des Kontextes einer von Azure Core abhängigen Azure SDK-Clientbibliothek verwenden, liegt es in Ihrer Verantwortung, die Lebensdauer von Token und das Zwischenspeichern in Ihrer App zu verwalten.

Die RefreshOn-Eigenschaft für AccessToken, die Verbrauchern einen Hinweis gibt, wann die Tokenaktualisierung versucht werden kann, wird automatisch von Azure SDK-Clientbibliotheken verwendet, die von der Azure Core-Bibliothek abhängen, um das Token zu aktualisieren. Bei der direkten Verwendung von die Token-Zwischenspeicherung unterstützenden Anmeldeinformationen der Azure Identity-Bibliothek, wird der zugrunde liegende MSAL-Cache automatisch proaktiv zum RefreshOn-Zeitpunkt aktualisiert. Mit diesem Design kann der Clientcode GetToken jedes Mal aufrufen, wenn ein Token benötigt wird, und die Aktualisierung an die Bibliothek delegieren.

Um GetToken nur bei Bedarf aufzurufen, beobachten Sie das RefreshOn Datum, und versuchen Sie proaktiv, das Token nach dieser Zeit zu aktualisieren. Die spezifische Implementierung liegt beim Kunden.

Verständnis der Wiederholungsstrategie für verwaltete Identitäten

Mit der Azure Identity-Bibliothek für .NET können Sie sich über verwaltete Identität mit ManagedIdentityCredentialauthentifizieren. Der Modus ManagedIdentityCredential, in dem Sie arbeiten, beeinflusst die angewendete Wiederholungsstrategie.

Modus "schnelles Scheitern"

  • Verwendungsbedingungen: Für lokale Entwicklungsszenarien, in denen Sie schnelles Feedback wünschen
  • So aktivieren Sie Folgendes: Verwenden Sie DefaultAzureCredential auf eine der folgenden Arten:
    • Ohne Festlegung der Umgebungsvariable AZURE_TOKEN_CREDENTIALS
    • Wenn die Umgebungsvariable AZURE_TOKEN_CREDENTIALS auf eine andere Zeichenfolge als ManagedIdentityCredential gesetzt ist
  • Funktionsweise: Es werden keine Wiederholungen versucht, wenn der anfängliche Tokenakquisitionsversuch nach kurzer Dauer fehlschlägt oder ausfällt. Dies ist der am wenigsten robuste Modus, da er für eine effiziente interne Entwicklungsschleife optimiert ist, die darauf ausgelegt ist, schnell zu scheitern („fail fast“).

Widerstandsfähiger Modus

  • Verwendungsbedingungen: Für Produktionsszenarien, in denen Resilienz wichtig ist

  • So aktivieren Sie Folgendes: Führen Sie einen der folgenden Ansätze aus:

    • Verwenden Sie DefaultAzureCredential mit der Umgebungsvariable AZURE_TOKEN_CREDENTIALS gesetzt auf ManagedIdentityCredential

      Wichtig

      Dieser DefaultAzureCredential Ansatz funktioniert nur im ausfallsicheren Modus bei Verwendung der Azure.Identity Paketversion 1.16.0 oder höher. In früheren Versionen wird dieser Ansatz im Modus "Fail fast" ausgeführt.

    • Verwenden von ChainedTokenCredential mit ManagedIdentityCredential

    • Verwenden Sie ManagedIdentityCredential direkt

  • Funktionsweise: Das Zeitintervall zwischen Wiederholungen beginnt bei 0,8 Sekunden, und standardmäßig werden maximal fünf Wiederholungen mit exponentiellem Backoff versucht. Dieser Modus ist für Resilienz optimiert, führt aber potenziell unerwünschte Verzögerungen in der inneren Entwicklungsschleife ein.

    Um die Standardeinstellungen für wiederholungen zu ändern, verwenden Sie die Retry Eigenschaft für DefaultAzureCredentialOptions oder ManagedIdentityCredentialOptions. Versuchen Sie es beispielsweise maximal dreimal mit einem Startintervall von 0,5 Sekunden:

    ManagedIdentityCredentialOptions miCredentialOptions = new(
        ManagedIdentityId.FromUserAssignedClientId(clientId)
    )
    {
        Retry =
        {
            MaxRetries = 3,
            Delay = TimeSpan.FromSeconds(0.5),
        }
    };

ManagedIdentityCredential miCredential = new(miCredentialOptions);

    Weitere Informationen zum Anpassen von Wiederholungsrichtlinien finden Sie unter Festlegen einer benutzerdefinierten Wiederholungsrichtlinie.

  • Last updated on