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 Produktions-Apps zu verhindern, sollten Sie dringend in Betracht ziehen, von DefaultAzureCredential zu einer der folgenden deterministischen Lösungen zu wechseln:

• Eine bestimmte TokenCredential-Implementierung, z. B. ManagedIdentityCredential. Die Optionen finden Sie in der Liste Abgeleitet.
• Eine reduzierte ChainedTokenCredential-Implementierung, die für die Azure-Umgebung, in der Ihre App ausgeführt wird, optimiert ist. ChainedTokenCredential erstellt im Wesentlichen eine spezifische Liste zulässiger Anmeldeinformationen, wie z. B. ManagedIdentity für die Produktion und VisualStudioCredential für die Entwicklung.

Betrachten Sie beispielsweise die folgende DefaultAzureCredential Konfiguration in einem ASP.NET Core-Projekt:

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

    DefaultAzureCredential credential = new();
    clientBuilder.UseCredential(credential);
});

Ersetzen Sie den vorherigen Code durch eine ChainedTokenCredential Implementierung, die nur die erforderlichen Anmeldeinformationen angibt:

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

    clientBuilder.UseCredential(new ChainedTokenCredential(
        new ManagedIdentityCredential(clientId: userAssignedClientId),
        new VisualStudioCredential()));
});

In diesem Beispiel würde ManagedIdentityCredential automatisch in der Produktion erkannt, während VisualStudioCredential in lokalen Entwicklungsumgebungen funktionieren würde.

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.

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

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(new Uri("<key-vault-url>"));
    clientBuilder.AddBlobServiceClient(new Uri("<blob-storage-url>"));

    string? clientId = builder.Configuration["UserAssignedClientId"];

    TokenCredential credential = clientId is not null
        ? new ManagedIdentityCredential(
            ManagedIdentityId.FromUserAssignedClientId(clientId))
        : new ChainedTokenCredential(
            new VisualStudioCredential(),
            new AzureCliCredential(),
            new AzurePowerShellCredential());

    clientBuilder.UseCredential(credential);
});

private void testBrokeredAuth_Click(object sender, RoutedEventArgs e)
{
    IntPtr windowHandle = new WindowInteropHelper(this).Handle;
    InteractiveBrowserCredential credential = new(
        new InteractiveBrowserCredentialBrokerOptions(windowHandle)
        {
            UseDefaultBrokerAccount = true,
        });

    BlobServiceClient blobServiceClient = new(
        new Uri("<blob-storage-url>"),
        credential);

    SecretClient secretClient = new(
        new Uri("<key-vault-url>"),
        credential);
}

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. Die Art und Weise, in der Sie ManagedIdentityCredential verwenden, wirkt sich auf die angewendete Wiederholungsstrategie aus. Bei Verwendung über:

• DefaultAzureCredential werden keine Wiederholungen versucht, wenn der anfängliche Tokenerwerbsversuch nach kurzer Dauer fehlschlägt oder ausfällt. Dies ist die wenigst robuste Option, da sie so optimiert ist, dass sie möglichst schnell scheitert, um eine effiziente interne Entwicklungsschleife zu fördern.
• Jeder andere Ansatz, z. B. ChainedTokenCredential oder ManagedIdentityCredential direkt:

  • Das Zeitintervall zwischen Wiederholungsversuchen beginnt bei 0,8 Sekunden, und standardmäßig werden maximal fünf Wiederholungsversuche versucht. Diese Option ist für Resilienz optimiert, führt aber potenziell unerwünschte Verzögerungen in der inneren Schleife der Entwicklung ein.

  • Wenn Sie eine der Standardeinstellungen für die Wiederholung ändern möchten, verwenden Sie die eigenschaft Retry für 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),
            }
        };
        ChainedTokenCredential tokenChain = new(
            new ManagedIdentityCredential(miCredentialOptions),
            new VisualStudioCredential()
        );
    

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