Procedimientos recomendados de autenticación con la biblioteca de identidades de Azure para .NET

En este artículo se ofrecen instrucciones que le ayudarán a maximizar el rendimiento y la confiabilidad de las aplicaciones .NET al autenticarse en los servicios de Azure. Para aprovechar al máximo la biblioteca de identidades de Azure para .NET, es importante comprender posibles problemas y técnicas de mitigación.

Uso de credenciales deterministas en entornos de producción

DefaultAzureCredential es la manera más accesible de empezar a trabajar con la biblioteca de identidades de Azure, pero esa comodidad también introduce ciertos compromisos. En particular, no se puede garantizar de antemano la credencial específica de la cadena que será exitosa y se usará para la autenticación de solicitudes. En un entorno de producción, esta imprevisibilidad puede presentar problemas significativos y a veces sutiles.

Por ejemplo, considere la siguiente secuencia hipotética de eventos:

1. El equipo de seguridad de una organización exige que todas las aplicaciones usen la identidad administrada para autenticarse en los recursos de Azure.
2. Durante meses, una aplicación .NET hospedada en una máquina virtual (VM) de Azure usa correctamente DefaultAzureCredential para autenticarse a través de una identidad administrada.
3. Sin indicarlo al equipo de soporte técnico, un desarrollador instala la CLI de Azure en esa máquina virtual y ejecuta el comando az login para autenticarse en Azure.
4. Debido a un cambio de configuración independiente en el entorno de Azure, la autenticación a través de la identidad administrada original comienza inesperadamente a producir un error en modo silencioso.
5. DefaultAzureCredential omite el ManagedIdentityCredential que falló y busca la siguiente credencial disponible, que es AzureCliCredential.
6. La aplicación comienza a usar las credenciales de la CLI de Azure en lugar de la identidad administrada, lo que puede producir un error o provocar una elevación o reducción inesperada de privilegios.

Para evitar estos tipos de problemas sutiles o errores silenciosos en aplicaciones de producción, reemplace por DefaultAzureCredential una implementación específica TokenCredential , como ManagedIdentityCredential. Consulte la lista de Derived para ver las opciones.

Por ejemplo, considere la siguiente configuración de DefaultAzureCredential en un proyecto de 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);
});

Modifique el código anterior para seleccionar una credencial basada en el entorno en el que se ejecuta la aplicación:

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

En este ejemplo, solo ManagedIdentityCredential se usa en producción. Las necesidades de autenticación del entorno de desarrollo local son atendidas por la secuencia de credenciales definida en la cláusula else.

Reutilización de instancias de credenciales

Vuelva a usar las instancias de credenciales siempre que sea posible para mejorar la resistencia de la aplicación y reducir el número de solicitudes de token de acceso emitidas a Microsoft Entra ID. Cuando se reutiliza una credencial, se intenta capturar un token de la caché de tokens de la aplicación administrada por la dependencia de MSAL subyacente. Para más información, consulte el almacenamiento en caché de tokens de en la biblioteca cliente de Azure Identity.

La estrategia de reutilización de credenciales recomendada difiere según el tipo de aplicación .NET.

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

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

Comprender cuándo se necesita la duración del token y la lógica de almacenamiento en caché

Si usa una credencial de la biblioteca de identidades de Azure fuera del contexto de una biblioteca de cliente del SDK de Azure que depende de Azure Core, es su responsabilidad administrar la duración del token y el comportamiento de almacenamiento en caché en su aplicación.

La propiedad RefreshOn en AccessToken, que proporciona una sugerencia a los consumidores sobre cuándo se puede intentar actualizar el token, será utilizada automáticamente por las bibliotecas cliente del SDK de Azure que dependen de la biblioteca Azure Core para actualizar el token. Para el uso directo de las credenciales de la biblioteca de identidades de Azure que admiten el almacenamiento en caché de tokens, la caché subyacente de MSAL se actualiza automáticamente cuando llega el momento de RefreshOn. Este diseño permite al código de cliente llamar a GetToken cada vez que se necesita un token y delegar la actualización en la biblioteca.

Para llamar solo a GetToken cuando sea necesario, observe la fecha de RefreshOn e intente actualizar el token de forma proactiva después de ese tiempo. La implementación específica queda a discreción del cliente.

Comprender la estrategia de reintento de identidad administrada

La biblioteca de identidades de Azure para .NET permite autenticarse a través de una identidad administrada con ManagedIdentityCredential. La forma en la que usas ManagedIdentityCredential influye en la estrategia de reintento aplicada. Cuando se utiliza a través de:

• DefaultAzureCredential, no se intenta ningún reintento cuando falla el intento inicial de adquisición de tokens o se agota el tiempo de espera. Esta es la opción menos resistente porque está optimizada para "fallar rápidamente" para un bucle interno de desarrollo eficaz.
• Cualquier otro enfoque, como ChainedTokenCredential o ManagedIdentityCredential directamente:

  • El intervalo de tiempo entre reintentos empieza en 0,8 segundos y se intenta un máximo de cinco reintentos de forma predeterminada. Esta opción está optimizada para resistencia, pero presenta retrasos potencialmente no deseados en el bucle interno de desarrollo.

  • Para cambiar cualquiera de los valores de reintento predeterminados, use la propiedad Retry en ManagedIdentityCredentialOptions. Por ejemplo, vuelva a intentar un máximo de tres veces, con un intervalo inicial de 0,5 segundos:

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

Para obtener más información sobre cómo personalizar las directivas de reintento, consulte Configuración de una directiva de reintento personalizada.