Najlepsze rozwiązania dotyczące uwierzytelniania w bibliotece tożsamości platformy Azure dla platformy .NET

Ten artykuł zawiera wskazówki ułatwiające zmaksymalizowanie wydajności i niezawodności aplikacji platformy .NET podczas uwierzytelniania w usługach platformy Azure. Aby jak najlepiej wykorzystać bibliotekę tożsamości platformy Azure dla platformy .NET, ważne jest, aby zrozumieć potencjalne problemy i techniki ograniczania ryzyka.

Używanie poświadczeń deterministycznych w środowiskach produkcyjnych

DefaultAzureCredential jest najbardziej przystępnym sposobem rozpoczęcia pracy z biblioteką tożsamości platformy Azure, ale ta wygoda wprowadza również pewne kompromisy. Przede wszystkim nie można z góry zagwarantować, które konkretne poświadczenie w łańcuchu powiedzie się i zostanie użyte do uwierzytelnienia żądania. W środowisku produkcyjnym ta nieprzewidywalność może powodować znaczące, a czasami subtelne problemy.

Rozważmy na przykład następującą hipotetyczną sekwencję zdarzeń:

1. Zespół ds. zabezpieczeń organizacji nakazuje wszystkim aplikacjom używanie tożsamości zarządzanej do uwierzytelniania w zasobach platformy Azure.
2. Przez wiele miesięcy aplikacja .NET hostowana na maszynie wirtualnej platformy Azure pomyślnie używa DefaultAzureCredential do uwierzytelniania za pośrednictwem tożsamości zarządzanej.
3. Bez poinformowania zespołu wsparcia technicznego, deweloper instaluje Azure CLI na tej VM i uruchamia polecenie az login w celu uwierzytelnienia w Azure.
4. Ze względu na oddzielną zmianę konfiguracji w środowisku Azure, uwierzytelnianie za pośrednictwem oryginalnej tożsamości zarządzanej nieoczekiwanie przestaje działać bez wyraźnego błędu.
5. DefaultAzureCredential pomija nieudane ManagedIdentityCredential i wyszukuje następne dostępne poświadczenie, które jest AzureCliCredential.
6. Aplikacja zaczyna używać poświadczeń Azure CLI zamiast tożsamości zarządzanej, co może prowadzić do niepowodzenia lub powodować nieoczekiwane podniesienie albo obniżenie uprawnień.

Aby zapobiec tym typom subtelnych problemów lub niepowodzeń dyskretnych w aplikacjach produkcyjnych, zastąp DefaultAzureCredential konkretną implementacją TokenCredential, taką jak ManagedIdentityCredential. Zobacz listę pochodnych , aby poznać opcje.

Rozważmy na przykład następującą konfigurację DefaultAzureCredential w projekcie ASP.NET Core:

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

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

Zmodyfikuj powyższy kod, aby wybrać poświadczenia na podstawie środowiska, w którym działa aplikacja:

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);
});

W tym przykładzie tylko ManagedIdentityCredential jest używana w środowisku produkcyjnym. Potrzeby uwierzytelniania lokalnego środowiska deweloperskiego są następnie obsługiwane przez sekwencję poświadczeń zdefiniowanych w klauzuli else.

Ponowne użycie instancji poświadczeń

Ponownie używaj instancji poświadczeń, jeśli to możliwe, aby zwiększyć odporność aplikacji i zmniejszyć liczbę żądań tokenów dostępu wystawionych dla Microsoft Entra ID. Gdy poświadczenie zostanie ponownie użyte, próbuje się pobrać token z pamięci podręcznej tokenu aplikacji zarządzanej przez zależność MSAL. Aby uzyskać więcej informacji, zobacz buforowanie tokenów w bibliotece klienta tożsamości platformy Azure.

Ważny

Aplikacja o dużym natężeniu, która nie używa ponownie poświadczeń, może napotkać odpowiedzi HTTP 429 dotyczące ograniczania przepustowości z Microsoft Entra ID, co może prowadzić do awarii aplikacji.

Zalecana strategia ponownego użycia poświadczeń różni się od typu aplikacji platformy .NET.

ASP.NET Core

Aby zaimplementować ponowne użycie poświadczeń, użyj metody UseCredential z Microsoft.Extensions.Azure. Rozważ aplikację ASP.NET Core hostowaną w usłudze Azure App Service w środowiskach produkcyjnych i przejściowych. Zmienna środowiskowa ASPNETCORE_ENVIRONMENT jest ustawiona na Production lub Staging, aby odróżnić te dwa środowiska nieprogramowania. W środowisku produkcyjnym i przejściowym wariant ManagedIdentityCredential przypisany przez użytkownika jest używany do uwierzytelniania wpisów tajnych usługi Key Vault i klientów usługi Blob Storage.

Gdy aplikacja jest uruchamiana na lokalnej maszynie deweloperskiej, gdzie ASPNETCORE_ENVIRONMENT jest ustawione na Development, zamiast tego używana jest sekwencja połączonych poświadczeń narzędzi deweloperskich. Takie podejście zapewnia, że używane są poświadczenia odpowiednie dla środowiska, zwiększając bezpieczeństwo i upraszczając zarządzanie poświadczeniami.

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);
});

Aby uzyskać informacje na temat tego podejścia w aplikacji ASP.NET Core, zobacz Uwierzytelnianie przy użyciu identyfikatora Entra firmy Microsoft.

inne

W aplikacjach, które nie są oparte na ASP.NET Core, ponowne użycie poświadczeń odbywa się przez przekazanie tego samego wystąpienia poświadczeń do każdego konstruktora klienta. Załóżmy na przykład, że aplikacja WPF korzysta z brokera uwierzytelniania w systemie Windows.

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);
}

Zrozum, kiedy potrzebny jest czas życia tokenu i logika buforowania

Jeśli używasz poświadczeń biblioteki tożsamości platformy Azure poza kontekstem biblioteki klienta zestawu Azure SDK, która zależy od usługi Azure Core, odpowiedzialność za zarządzanie okresem istnienia tokenu i zachowaniem buforowania w aplikacji staje się Twoim zadaniem.

Właściwość RefreshOn w AccessToken, która udostępnia wskazówkę dla użytkowników co do tego, kiedy można podjąć próbę odświeżenia tokenu, będzie automatycznie używana przez biblioteki klienckie zestawu Azure SDK, które zależą od biblioteki platformy Azure Core w celu odświeżenia tokenu. W przypadku użycia bezpośrednio biblioteki Azure Identity z poświadczeniami obsługującymi buforowanie tokenów, podstawowa pamięć podręczna MSAL odświeża się automatycznie i proaktywnie, kiedy nadejdzie określony czas RefreshOn. Ten projekt umożliwia kodowi klienta wywoływanie GetToken za każdym razem, gdy potrzebny jest token, aby delegowanie odświeżania odbywało się przez bibliotekę.

Aby wywołać GetToken tylko wtedy, gdy jest to konieczne, obserwuj datę RefreshOn i proaktywnie spróbuj odświeżyć token po tym czasie. Konkretna implementacja należy do klienta.

Zrozumienie strategii ponawiania prób tożsamości zarządzanej

Biblioteka Azure Identity dla .NET umożliwia uwierzytelnianie za pośrednictwem tożsamości zarządzanej za pomocą ManagedIdentityCredential. Sposób używania ManagedIdentityCredential wpływa na zastosowaną strategię ponawiania prób. W przypadku użycia za pośrednictwem:

• DefaultAzureCredential, nie są podejmowane żadne próby ponowienia, gdy początkowa próba uzyskania tokenu zakończy się niepowodzeniem lub po krótkim czasie upłynie limit czasu. Jest to najmniej odporna opcja, ponieważ jest zoptymalizowana pod kątem "szybkiego niepowodzenia" dla wydajnej pętli wewnętrznej programowania.
• Inne podejście, takie jak ChainedTokenCredential lub ManagedIdentityCredential bezpośrednio:

  • Interwał czasu między ponowną próbą rozpoczyna się od 0,8 sekundy, a domyślnie jest podejmowana próba maksymalnie pięciu ponownych prób. Ta opcja jest zoptymalizowana pod kątem odporności, ale wprowadza potencjalnie niepożądane opóźnienia w pętli wewnętrznej programowania.

  • Aby zmienić dowolne domyślne ustawienia ponawiania prób, użyj właściwości Retry w ManagedIdentityCredentialOptions. Na przykład spróbuj ponownie maksymalnie trzy razy z interwałem początkowym wynoszącym 0,5 sekundy:

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

Aby uzyskać więcej informacji na temat dostosowywania zasad ponawiania, zobacz Ustawianie niestandardowych zasad ponawiania.