Bonnes pratiques d’authentification avec la bibliothèque Azure Identity pour .NET

Cet article propose des instructions pour vous aider à optimiser les performances et la fiabilité de vos applications .NET lors de l’authentification auprès des services Azure. Pour tirer le meilleur parti de la bibliothèque Azure Identity pour .NET, il est important de comprendre les problèmes potentiels et les techniques d’atténuation.

Utiliser des informations d’identification déterministes dans des environnements de production

DefaultAzureCredential est la manière la plus accessible pour commencer à utiliser la bibliothèque d’identités Azure, mais cette commodité introduit également certains compromis. Surtout, il n’est pas possible de garantir à l’avance que l’identifiant spécifique dans la chaîne, qui réussira et sera utilisé pour l’authentification de la requête, sera toujours celui attendu. Dans un environnement de production, cette impdictibilité peut introduire des problèmes significatifs et parfois subtils.

Par exemple, considérez la séquence hypothétique suivante d’événements :

1. L’équipe de sécurité d’une organisation impose à toutes les applications d’utiliser l’identité managée pour s’authentifier auprès des ressources Azure.
2. Pendant des mois, une application .NET hébergée sur une machine virtuelle Azure utilise correctement DefaultAzureCredential pour s’authentifier via une identité managée.
3. Sans indiquer à l’équipe de support technique, un développeur installe Azure CLI sur cette machine virtuelle et exécute la commande az login pour s’authentifier auprès d’Azure.
4. En raison d’une modification de configuration distincte dans l’environnement Azure, l’authentification via l’identité managée d’origine commence de manière inattendue à échouer en mode silencieux.
5. DefaultAzureCredential ignore l’échec de ManagedIdentityCredential et recherche le prochain identifiant disponible, qui est AzureCliCredential.
6. L’application commence à utiliser les informations d’identification Azure CLI plutôt que l’identité managée, ce qui peut échouer ou entraîner une élévation ou une réduction inattendue des privilèges.

Pour éviter ces types de problèmes subtils ou d’échecs silencieux dans les applications de production, remplacez DefaultAzureCredential par une implémentation de TokenCredential spécifique, telle que ManagedIdentityCredential. Consultez la liste Dérivé pour plus d'options.

Par exemple, considérez la configuration de DefaultAzureCredential suivante dans un projet 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);
});

Modifiez le code précédent pour sélectionner des informations d’identification en fonction de l’environnement dans lequel l’application s’exécute :

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

Dans cet exemple, seule ManagedIdentityCredential est utilisée en production. Les besoins d’authentification de l’environnement de développement local sont ensuite serviceés par la séquence d’informations d’identification définies dans la clause else.

Réutiliser les instances d'identifiants

Réutilisez les instances d’informations d’identification lorsque cela est possible pour améliorer la résilience des applications et réduire le nombre de demandes de jeton d’accès émises à l’ID Microsoft Entra. Lorsqu’une information d’identification est réutilisée, une tentative est effectuée pour extraire un jeton du cache de jetons d’application géré par la dépendance MSAL sous-jacente. Pour plus d’informations, consultez la mise en cache des jetons dans la bibliothèque cliente Azure Identity.

Important

Une application à volume élevé qui ne réutilise pas les informations d’identification risque de subir des réponses de limitation HTTP 429 de Microsoft Entra ID, ce qui peut entraîner des interruptions de service.

La stratégie de réutilisation des informations d’identification recommandée diffère du type d’application .NET.

ASP.NET Core

Pour implémenter la réutilisation des informations d’identification, utilisez la méthode UseCredential à partir de Microsoft.Extensions.Azure. Considérez une application ASP.NET Core hébergée sur Azure App Service dans les environnements de production et de préproduction. La variable d’environnement ASPNETCORE_ENVIRONMENT est définie sur Production ou Staging pour différencier ces deux environnements sans développement. Tant en production qu'en préproduction, la variante de ManagedIdentityCredential assignée par l'utilisateur est utilisée pour authentifier les clients des secrets Key Vault et du Stockage Blob.

Lorsque l’application s’exécute sur un ordinateur de développement local, où ASPNETCORE_ENVIRONMENT est défini sur Development, une séquence chaînée d’informations d’identification de l’outil de développement est utilisée à la place. Cette approche garantit que les informations d’identification appropriées à l’environnement sont utilisées, ce qui améliore la sécurité et simplifie la gestion des informations d’identification.

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

Pour obtenir des informations sur cette approche dans une application ASP.NET Core, consultez Authentification à l’aide de Microsoft Entra ID.

Autres

Dans non-ASP.NET applications Core, la réutilisation des informations d’identification est effectuée en passant la même instance d’informations d’identification à chaque constructeur client. Par exemple, imaginez une application WPF à l’aide du répartiteur d’authentification sur 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);
}

Comprendre quand la durée de vie des jetons et la logique de mise en cache sont nécessaires

Si vous utilisez un identifiant de bibliothèque Azure Identity en dehors du contexte d'une bibliothèque client Azure SDK qui dépend d'Azure Core, il vous incombe de gérer la durée de vie du jeton et le comportement de mise en cache dans votre application.

La propriété RefreshOn sur AccessToken, qui fournit un conseil aux consommateurs quant au moment où l’actualisation des jetons peut être tentée, sera automatiquement utilisée par les bibliothèques clientes du Kit de développement logiciel (SDK) Azure qui dépendent de la bibliothèque Azure Core pour actualiser le jeton. Pour l'utilisation directe des informations d'identification de la bibliothèque Azure Identity qui prennent en charge la mise en cache des jetons, le cache MSAL sous-jacent s'actualise automatiquement de manière proactive lorsque le moment RefreshOn se produit. Cette conception permet au code client d’appeler GetToken chaque fois qu’un jeton est nécessaire et de déléguer l’actualisation à la bibliothèque.

Pour appeler uniquement GetToken si nécessaire, surveillez la date RefreshOn et tentez d'actualiser le jeton de manière proactive après cette date. L’implémentation spécifique est à la hauteur du client.

Comprendre la stratégie de nouvelle tentative d’identité managée

La bibliothèque d’identités Azure pour .NET vous permet de vous authentifier via une identité managée avec ManagedIdentityCredential. La façon dont vous utilisez ManagedIdentityCredential affecte la stratégie de nouvelle tentative appliquée. Lorsqu’il est utilisé via :

• DefaultAzureCredential, aucune nouvelle tentative n’est tentée lorsque la tentative d’acquisition de jeton initiale échoue ou expire après une courte durée. Il s’agit de l’option la moins résiliente, car elle est optimisée pour « échouer rapidement » pour une boucle interne de développement efficace.
• Toute autre approche, comme ChainedTokenCredential ou ManagedIdentityCredential directement :

  • L’intervalle de temps entre les nouvelles tentatives commence à 0,8 secondes et un maximum de cinq nouvelles tentatives sont tentées, par défaut. Cette option est optimisée pour la résilience, mais introduit des retards potentiellement indésirables dans la boucle interne de développement.

  • Pour modifier l’un des paramètres de nouvelle tentative par défaut, utilisez la propriété Retry sur ManagedIdentityCredentialOptions. Par exemple, réessayez trois fois au maximum, avec un intervalle de départ de 0,5 secondes :

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

Pour plus d’informations sur la personnalisation des stratégies de nouvelle tentative, consultez Définition d’une stratégie de nouvelle tentative personnalisée.