Metodtips för autentisering med Azure Identity-biblioteket för .NET

Den här artikeln innehåller riktlinjer som hjälper dig att maximera prestanda och tillförlitlighet för dina .NET-appar när du autentiserar till Azure-tjänster. För att få ut mesta möjliga av Azure Identity-biblioteket för .NET är det viktigt att förstå potentiella problem och riskreduceringstekniker.

Använda deterministiska autentiseringsuppgifter i produktionsmiljöer

DefaultAzureCredential är det mest lättillgängliga sättet att komma igång med Azure Identity-biblioteket, men den bekvämligheten medför också vissa kompromisser. Framför allt kan de specifika autentiseringsuppgifterna i kedjan som ska lyckas och användas för autentisering av begäranden inte garanteras i förväg. I en produktionsmiljö kan den här oförutsägbarheten medföra betydande och ibland subtila problem.

Tänk till exempel på följande hypotetiska händelsesekvens:

1. En organisations säkerhetsteam kräver att alla appar använder hanterad identitet för att autentisera till Azure-resurser.
2. Under flera månader har en .NET-app varit värd på en virtuell Azure-dator (VM) och använt DefaultAzureCredential för att autentisera via hanterad identitet.
3. Utan att berätta för supportteamet installerar en utvecklare Azure CLI på den virtuella datorn och kör kommandot az login för att autentisera till Azure.
4. På grund av en separat konfigurationsändring i Azure-miljön börjar autentiseringen via den ursprungliga hanterade identiteten oväntat misslyckas tyst.
5. DefaultAzureCredential hoppar över den misslyckade ManagedIdentityCredential och söker efter nästa tillgängliga autentiseringsuppgifter, vilket är AzureCliCredential.
6. Programmet börjar använda Azure CLI-autentiseringsuppgifterna i stället för den hanterade identiteten, vilket kan misslyckas eller leda till oväntad höjning eller minskning av behörigheter.

Om du vill förhindra dessa typer av subtila problem eller tysta fel i produktionsappar ersätter du DefaultAzureCredential med en specifik TokenCredential implementering, till exempel ManagedIdentityCredential. Se den härledda listan för alternativ.

Tänk till exempel på följande DefaultAzureCredential konfiguration i ett ASP.NET Core-projekt:

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

Ändra föregående kod för att välja en autentiseringsuppgift baserat på miljön där appen körs:

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

I det här exemplet används endast ManagedIdentityCredential i produktion. Den lokala utvecklingsmiljöns autentiseringsbehov hanteras sedan av sekvensen med autentiseringsuppgifter som definieras i else-satsen.

Återanvänd autentiseringsinstanser

Återanvänd instanser av autentiseringsuppgifter när det är möjligt för att förbättra appåterhämtningen och minska antalet begäranden om åtkomsttoken som utfärdas till Microsoft Entra-ID. När en autentiseringsuppgift återanvänds görs ett försök att hämta en token från apptokencache som hanteras av det underliggande MSAL-beroendet. Mer information finns i cachelagring av token i Azure Identity-klientbiblioteket.

Den rekommenderade strategin för återanvändning av autentiseringsuppgifter skiljer sig åt efter .NET-programtyp.

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

Förstå när tokens livslängd och cachelagringslogik behövs

Om du använder Azure Identity-biblioteks autentiseringsuppgifter utanför kontexten för ett Azure SDK-klientbibliotek som är beroende av Azure Core, är du ansvarig för att hantera tokenlivslängd och cachelagringsbeteende i din app.

Egenskapen RefreshOn på AccessToken, som ger ett tips till konsumenter om när tokenuppdatering kan försökas, används automatiskt av Azure SDK-klientbibliotek som är beroende av Azure Core-biblioteket för att uppdatera token. Vid direkt användning av autentiseringsuppgifter från Azure Identity Library som stöder cachelagring av tokenuppdateras MSAL-cachen automatiskt och proaktivt vid tidpunkten RefreshOn. Med den här designen kan klientkoden anropa GetToken varje gång en token behövs och delegera uppdateringen till biblioteket.

Om du bara vill anropa GetToken vid behov kan du observera RefreshOn datum och proaktivt försöka uppdatera token efter den tiden. Den specifika implementeringen är upp till kunden.

Förstå strategin för återförsök av hanterad identitet

Med Azure Identity-biblioteket för .NET kan du autentisera via hanterad identitet med ManagedIdentityCredential. Det sätt på vilket du använder ManagedIdentityCredential påverkar den tillämpade återförsöksstrategin. När det används via:

• DefaultAzureCredentialgörs inga återförsök när det första tokeninsamlingsförsöket misslyckas eller överskrider tidsgränsen efter en kort tid. Det här är det minst motståndskraftiga alternativet eftersom det är optimerat för att "misslyckas snabbt" för en effektiv inre loop för utveckling.
• Andra metoder, till exempel ChainedTokenCredential eller ManagedIdentityCredential direkt:

  • Tidsintervallet mellan återförsök börjar vid 0,8 sekunder och högst fem återförsök görs som standard. Det här alternativet är optimerat för motståndskraft men medför potentiellt oönskade fördröjningar i den inre utvecklingsloopen.

  • Om du vill ändra någon av standardinställningarna för återförsök använder du egenskapen Retry på ManagedIdentityCredentialOptions. Försök till exempel igen högst tre gånger med ett startintervall på 0,5 sekunder:

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

Mer information om hur du anpassar återförsöksprinciper finns i Ange en anpassad återförsöksprincip.