Sdílet prostřednictvím

Osvědčené postupy ověřování s využitím knihovny Identit Azure pro .NET

Tento článek nabízí pokyny, které vám pomůžou maximalizovat výkon a spolehlivost aplikací .NET při ověřování ve službách Azure. Pokud chcete využít knihovnu Identit Azure pro .NET na maximum, je důležité porozumět potenciálním problémům a technikám zmírnění rizik.

Použití deterministických přihlašovacích údajů v produkčních prostředích

DefaultAzureCredential je nejpohodnější způsob, jak začít s knihovnou identit Azure, ale tato pohodlí přináší i určité kompromisy. Zejména konkrétní přihlašovací údaje v řetězci, které budou úspěšné a budou použity pro ověřování žádostí, není možné předem zaručit. V produkčním prostředí může tato nepředvídatelnost představovat významné a někdy drobné problémy.

Představte si například následující hypotetickou posloupnost událostí:

  1. Bezpečnostní tým organizace vyžaduje, aby všechny aplikace používaly spravovanou identitu k ověřování prostředků Azure.
  2. Po měsíce aplikace .NET hostovaná na virtuálním počítači Azure úspěšně používá DefaultAzureCredential k ověření prostřednictvím spravované identity.
  3. Vývojář na tento virtuální počítač nainstaluje Azure CLI a spustí příkaz az login pro ověření v Azure, aniž by řekl týmu podpory.
  4. Kvůli samostatné změně konfigurace v prostředí Azure začne ověřování prostřednictvím původní spravované identity neočekávaně tiše selhávat.
  5. DefaultAzureCredential přeskočí neúspěšné ManagedIdentityCredential a vyhledá další dostupné přihlašovací údaje, což je AzureCliCredential.
  6. Aplikace začne místo spravované identity využívat přihlašovací údaje Azure CLI, což může selhat nebo vést k neočekávanému zvýšení oprávnění nebo snížení oprávnění.

Chcete-li těmto typům drobných problémů nebo tichých selhání v produkčních aplikacích zabránit, nahraďte DefaultAzureCredential konkrétní TokenCredential implementací, například ManagedIdentityCredential. Možnosti najdete v odvozeném seznamu .

Představte si například následující konfiguraci v projektu ASP.NET Core. Instance DefaultAzureCredential je implicitně vytvořena a používána pro všechny registrované klienty služeb:

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(
        new Uri($"https://{keyVaultName}.vault.azure.net"));
    clientBuilder.AddBlobServiceClient(
        new Uri($"https://{storageAccountName}.blob.core.windows.net"));
});

Upravte předchozí kód tak, aby na základě prostředí, ve kterém je aplikace spuštěná, vybrali přihlašovací údaje:

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

V tomto příkladu se používá pouze ManagedIdentityCredential v produkčním prostředí. Požadavky na ověřování místního vývojového prostředí se pak obsluhují sekvencí přihlašovacích údajů definovaných v else klauzuli.

Opakované použití instancí autentizačních údajů

Pokud je to možné, použijte instance přihlašovacích údajů, pokud je to možné, abyste zlepšili odolnost aplikací a snížili počet žádostí o přístupový token vydaných pro Microsoft Entra ID. Při opětovném použití přihlašovacích údajů se provede pokus o načtení tokenu z mezipaměti tokenů aplikace spravované základní závislostí MSAL. Další informace najdete v tématu Ukládání tokenů do mezipaměti v klientské knihovně azure Identity.

Důležitý

Aplikace s vysokou zátěží, která znovu nepoužívá přihlašovací údaje, může narazit na omezení odpovědí HTTP 429 od Microsoft Entra ID, což může vést k výpadkům aplikace.

Doporučená strategie opětovného použití přihlašovacích údajů se liší podle typu aplikace .NET.

K implementaci opětovného použití přihlašovacích údajů použijte metodu UseCredential z Microsoft.Extensions.Azure. Zvažte ASP.NET základní aplikaci hostované ve službě Azure App Service v produkčním i přípravném prostředí. Proměnná prostředí ASPNETCORE_ENVIRONMENT je nastavena na hodnotu Production nebo Staging k rozlišení mezi těmito dvěma nevývojovými prostředími. V produkčním i přípravném prostředí se uživatelem přiřazená varianta ManagedIdentityCredential používá k autentizaci tajemství služby Key Vault a klientů služby Blob Storage.

Když aplikace běží na místním vývojovém počítači, kde ASPNETCORE_ENVIRONMENT je nastaveno na Development, použije se místo toho zřetězená posloupnost přihlašovacích údajů vývojářského nástroje. Tento přístup zajišťuje použití přihlašovacích údajů vhodných pro prostředí, zvýšení zabezpečení a zjednodušení správy přihlašovacích údajů.

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

Informace o tomto přístupu v aplikaci ASP.NET Core najdete v tématu Ověřování pomocí ID Microsoft Entra.

Vysvětlení, kdy je potřeba použít životnost tokenu a logiku ukládání do mezipaměti

Pokud používáte přihlašovací údaje knihovny Identit Azure mimo kontext klientské knihovny Azure SDK, která závisí naAzure Core, stane se vaší odpovědností spravovat platnost tokenu a chování při ukládání do mezipaměti ve vaší aplikaci.

Vlastnost RefreshOn v AccessToken, která uživatelům poskytuje nápovědu o tom, kdy mohou zkusit aktualizovat token, bude automaticky použita klientskými knihovnami sady Azure SDK, které závisejí na knihovně Azure Core k automatické aktualizaci tokenu. Pro přímé použití přihlašovacích údajů knihovny Azure Identity , které podporují ukládání tokenů do mezipaměti, se základní MSAL mezipaměť automaticky proaktivně aktualizuje, když nastane RefreshOn čas. Tento návrh umožňuje klientskému kódu volat GetToken pokaždé, když je potřeba token, a delegovat aktualizaci do knihovny.

Aby bylo možné volat GetToken pouze v případě potřeby, sledujte datum RefreshOn a proaktivně se po tomto datu pokuste token aktualizovat. Konkrétní implementace je na zákazníkovi.

Pochopte strategii opakování spravované identity

Identitní knihovna Azure pro .NET umožňuje autentizaci prostřednictvím spravované identity pomocí ManagedIdentityCredential. Režim, ve kterém použijete ManagedIdentityCredential , má vliv na použitou strategii opakování.

Režim rychlého selhání

  • Kdy použít: V případě místních vývojových scénářů, ve kterých potřebujete rychlou zpětnou vazbu
  • Postup aktivace: Použijte DefaultAzureCredential jedním z následujících způsobů:
    • Bez nastavení proměnné prostředí AZURE_TOKEN_CREDENTIALS
    • S proměnnou AZURE_TOKEN_CREDENTIALS prostředí nastavenou na jiný řetězec než ManagedIdentityCredential
  • Jak to funguje: Při selhání počátečního pokusu o získání tokenu nebo vypršení časového limitu po krátké době se nepokusí žádné opakování. Jedná se o nejodolnější režim, protože je optimalizovaný tak, aby rychle selhal pro efektivní vnitřní smyčku vývoje.

Odolný režim

  • Kdy použít: V produkčních scénářích, kdy je důležitá odolnost

  • Postup aktivace: Proveďte jeden z následujících přístupů:

    • Použití DefaultAzureCredential s proměnnou AZURE_TOKEN_CREDENTIALS prostředí nastavenou na ManagedIdentityCredential

      Důležitý

      Tento DefaultAzureCredential přístup funguje pouze v odolném režimu při použití Azure.Identity balíčku verze 1.16.0 nebo novější. V dřívějších verzích tento přístup pracuje v režimu rychlého selhání.

    • Použijte ChainedTokenCredential obsahující ManagedIdentityCredential

    • Přímé použití ManagedIdentityCredential

  • Jak to funguje: Časový interval mezi pokusy o opakování začíná na 0,8 sekundách a podle výchozího nastavení se pokusy provádějí maximálně pětkrát s exponenciálním odsouváním. Tento režim je optimalizovaný pro odolnost, ale představuje potenciálně nežádoucí zpoždění ve vnitřní smyčce vývoje.

    Chcete-li změnit výchozí nastavení opakování, použijte Retry vlastnost na DefaultAzureCredentialOptions nebo ManagedIdentityCredentialOptions. Zkuste například opakovat maximálně třikrát s počátečním intervalem 0,5 sekund:

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

ManagedIdentityCredential miCredential = new(miCredentialOptions);

    Další informace o přizpůsobení zásad opakování najdete v tématu Nastavení vlastní zásady opakování.

  • Last updated on