Partage via

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 suivante dans un projet ASP.NET Core. Une instance de DefaultAzureCredential est implicitement créée et utilisée pour tous les clients de service inscrits :

DefaultAzureCredential credential = new();
BlobServiceClient client = new(
    new Uri($"https://{storageAccountName}.blob.core.windows.net"),
    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.

Importante

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.

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.

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. Le mode dans lequel vous utilisez ManagedIdentityCredential a un impact sur la stratégie de nouvelle tentative appliquée.

Mode « Échec rapide »

  • Quand utiliser : Pour les scénarios de développement locaux dans lesquels vous souhaitez obtenir des commentaires rapides
  • Comment activer : Utilisez DefaultAzureCredential l’une des manières suivantes :
    • Sans définir la variable d’environnement AZURE_TOKEN_CREDENTIALS
    • Avec la variable AZURE_TOKEN_CREDENTIALS d’environnement définie sur une chaîne autre que ManagedIdentityCredential
  • Fonctionnement : 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 du mode le moins résilient, car il est optimisé pour « échouer rapidement » pour une boucle interne de développement efficace.

Mode résilient

  • Quand utiliser : Pour les scénarios de production où la résilience est importante

  • Comment activer : Suivez l’une des approches suivantes :

    • Utiliser DefaultAzureCredential avec la variable AZURE_TOKEN_CREDENTIALS d’environnement définie sur ManagedIdentityCredential

      Importante

      Cette DefaultAzureCredential approche fonctionne uniquement en mode résilient lors de l’utilisation Azure.Identity du package version 1.16.0 ou ultérieure. Dans les versions antérieures, cette approche fonctionne en mode « échec rapide ».

    • Utilisez ChainedTokenCredential contenant ManagedIdentityCredential

    • Utiliser ManagedIdentityCredential directement

  • Fonctionnement : L’intervalle de temps entre les réessais commence à 0,8 secondes et un maximum de cinq réessais sont tentés avec un recul exponentiel, par défaut. Ce mode est optimisé pour la résilience, mais introduit des retards potentiellement indésirables dans la boucle interne de développement.

    Pour modifier les paramètres de nouvelle tentative par défaut, utilisez la Retry propriété sur DefaultAzureCredentialOptions ou 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.

  • Last updated on