Condividi tramite

Procedure consigliate per l'autenticazione con la libreria di identità di Azure per .NET

  • Articolo

Questo articolo offre linee guida per ottimizzare le prestazioni e l'affidabilità delle app .NET durante l'autenticazione ai servizi di Azure. Per sfruttare al meglio la libreria di identità di Azure per .NET, è importante comprendere i potenziali problemi e le tecniche di mitigazione.

Usare credenziali deterministiche negli ambienti di produzione

DefaultAzureCredential è il modo più accessibile per iniziare a usare la libreria di identità di Azure, ma questa praticità introduce anche alcuni compromessi. In particolare, le credenziali specifiche nella catena che avranno esito positivo e che verranno usate per l'autenticazione della richiesta non possono essere garantite in anticipo. In un ambiente di produzione, questa imprevedibilità può introdurre problemi significativi e talvolta sottili.

Si consideri, ad esempio, la sequenza ipotetica di eventi seguente:

  1. Il team di sicurezza di un'organizzazione impone a tutte le app di usare l'identità gestita per l'autenticazione alle risorse di Azure.
  2. Per mesi, un'app .NET ospitata in una macchina virtuale di Azure usa correttamente DefaultAzureCredential per l'autenticazione tramite identità gestita.
  3. Senza indicare al team di supporto, uno sviluppatore installa l'interfaccia della riga di comando di Azure in tale macchina virtuale ed esegue il comando az login per l'autenticazione in Azure.
  4. A causa di una modifica di configurazione separata nell'ambiente Azure, l'autenticazione tramite l'identità gestita originale inizia in modo imprevisto a non riuscire in modo invisibile all'utente.
  5. DefaultAzureCredential ignora il ManagedIdentityCredential non riuscito e cerca le credenziali disponibili successive, ovvero AzureCliCredential.
  6. L'applicazione inizia a usare le credenziali dell'interfaccia della riga di comando di Azure anziché l'identità gestita, che potrebbe non riuscire o comportare un'elevazione o una riduzione imprevista dei privilegi.

Per evitare questi tipi di problemi sottili o errori invisibile all'utente nelle app di produzione, sostituire DefaultAzureCredential con un'implementazione di TokenCredential specifica, ad esempio ManagedIdentityCredential. Vedere l'elenco derivato per le opzioni.

Si consideri ad esempio la configurazione di DefaultAzureCredential seguente in un progetto 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);
});

Modificare il codice precedente per selezionare una credenziale in base all'ambiente in cui è in esecuzione l'app:

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

In questo esempio viene usato solo ManagedIdentityCredential nell'ambiente di produzione. Le esigenze di autenticazione dell'ambiente di sviluppo locale vengono quindi gestite dalla sequenza di credenziali definite nella clausola else.

Riutilizzare le istanze delle credenziali

Riutilizzare le istanze delle credenziali quando possibile per migliorare la resilienza delle app e ridurre il numero di richieste di token di accesso inviate a Microsoft Entra ID. Quando viene riutilizzata una credenziale, viene effettuato un tentativo di recuperare un token dalla cache dei token dell'app gestita dalla dipendenza MSAL sottostante. Per altre informazioni, vedere Memorizzazione nella cache dei token nella libreria client di Azure Identity.

Importante

Un'app con volumi elevati che non riutilizza le credenziali potrebbe riscontrare risposte di limitazione delle risorse HTTP 429 da Microsoft Entra ID, e ciò può portare a interruzioni dell'app.

La strategia di riutilizzo delle credenziali consigliata è diversa dal tipo di applicazione .NET.

Per implementare il riutilizzo delle credenziali, usare il metodo UseCredential da Microsoft.Extensions.Azure. Si consideri un'app core ASP.NET ospitata nel servizio app di Azure sia in ambienti di produzione che di gestione temporanea. La variabile di ambiente ASPNETCORE_ENVIRONMENT è impostata su Production o Staging per distinguere tra questi due ambienti non di sviluppo. Sia nell'ambiente di produzione che nell'ambiente di staging, la variante assegnata dall'utente di ManagedIdentityCredential viene utilizzata per autenticare i segreti di Key Vault e i client di Blob Storage.

Quando l'app viene eseguita in un computer di sviluppo locale, in cui ASPNETCORE_ENVIRONMENT è impostata su Development, viene invece usata una sequenza concatenata di credenziali dello strumento di sviluppo. Questo approccio garantisce l'uso delle credenziali appropriate per l'ambiente, il miglioramento della sicurezza e la semplificazione della gestione delle credenziali.

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

Per informazioni su questo approccio in un'app ASP.NET Core, vedere Autenticazione con Microsoft Entra ID.

Comprendere quando è necessaria la logica di memorizzazione nella cache e la durata dei token

Se si usano credenziali della libreria di identità di Azure al di fuori del contesto di una libreria client dell'SDK di Azure che dipende da Azure Core, diventa responsabilità dell'utente la gestione della durata di vita dei token e il comportamento di memorizzazione nella cache nell'app.

La proprietà RefreshOn in AccessToken, che fornisce un suggerimento ai consumer quando è possibile tentare l'aggiornamento del token, verrà usata automaticamente dalle librerie client di Azure SDK che dipendono dalla libreria Core di Azure per aggiornare il token. Per utilizzare direttamente le credenziali della libreria di identità di Azure , che supportano la memorizzazione nella cache dei token, la cache MSAL sottostante si aggiorna automaticamente in modo proattivo quando si verifica l'evento di RefreshOn. Questa progettazione consente al codice client di chiamare GetToken ogni volta che è necessario un token e delegare l'aggiornamento alla libreria.

Per chiamare GetToken solo quando necessario, osservare la data di RefreshOn e tentare in modo proattivo di aggiornare il token dopo tale ora. L'implementazione specifica spetta al cliente.

Comprendere la strategia di ripetizione dei tentativi per identità gestita

La libreria di identità di Azure per .NET consente di eseguire l'autenticazione tramite identità gestita con ManagedIdentityCredential. Il modo in cui si usa ManagedIdentityCredential influisce sulla strategia di ripetizione dei tentativi applicata. Se usato tramite:

  • DefaultAzureCredential, non vengono tentati tentativi quando il tentativo di acquisizione del token iniziale ha esito negativo o si verifica il timeout dopo un breve periodo di tempo. Questa è l'opzione meno resiliente perché è ottimizzata per un approccio di "fallimento rapido" per un ciclo interno di sviluppo efficiente.
  • Qualsiasi altro approccio, ad esempio ChainedTokenCredential o ManagedIdentityCredential direttamente:

    • L'intervallo di tempo tra i tentativi inizia a 0,8 secondi e viene effettuato un tentativo massimo di cinque tentativi per impostazione predefinita. Questa opzione è ottimizzata per la resilienza, ma introduce ritardi potenzialmente indesiderati nel ciclo interno di sviluppo.

    • Per modificare una delle impostazioni predefinite per i tentativi, usare la proprietà Retry in ManagedIdentityCredentialOptions. Ad esempio, ripetere un massimo di tre volte, con un intervallo di inizio di 0,5 secondi:

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

ManagedIdentityCredential miCredential = new(miCredentialOptions);

Per altre informazioni sulla personalizzazione dei criteri di ripetizione dei tentativi, vedere Impostazione di un criterio di ripetizione dei tentativi personalizzato.