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í.

Pokud chcete těmto typům drobných problémů nebo tichých selhání v produkčních aplikacích zabránit, důrazně zvažte přechod z DefaultAzureCredential na jedno z následujících deterministických řešení:

• Konkrétní TokenCredential implementace, například ManagedIdentityCredential. Možnosti najdete v odvozeném seznamu .
• Určitá implementace ChainedTokenCredential, redukovaná a optimalizovaná pro prostředí Azure, ve kterém vaše aplikace běží. ChainedTokenCredential v podstatě vytvoří konkrétní seznam povolených přijatelných možností přihlašovacích údajů, například ManagedIdentity pro produkční prostředí a VisualStudioCredential pro vývoj.

Představte si například následující konfiguraci DefaultAzureCredential v projektu ASP.NET Core:

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));

    DefaultAzureCredential credential = new();
    clientBuilder.UseCredential(credential);
});

Nahraďte předchozí kód implementací ChainedTokenCredential, která určuje pouze nezbytné přihlašovací údaje:

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));

    clientBuilder.UseCredential(new ChainedTokenCredential(
        new ManagedIdentityCredential(clientId: userAssignedClientId),
        new VisualStudioCredential()));
});

V tomto příkladu se ManagedIdentityCredential automaticky zjistí v produkčním prostředí, zatímco VisualStudioCredential bude fungovat v místních vývojových prostředích.

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.

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

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(new Uri("<key-vault-url>"));
    clientBuilder.AddBlobServiceClient(new Uri("<blob-storage-url>"));

    string? clientId = builder.Configuration["UserAssignedClientId"];

    TokenCredential credential = clientId is not null
        ? new ManagedIdentityCredential(
            ManagedIdentityId.FromUserAssignedClientId(clientId))
        : 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);
}

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. Způsob použití ManagedIdentityCredential ovlivňuje použitou strategii opakování. Při použití prostřednictvím:

• DefaultAzureCredential, pokud se pokus o získání počátečního tokenu nezdaří nebo vyprší časový limit, neopakují se žádné pokusy o obnovení. Jedná se o nejodolnější možnost, protože je optimalizovaná tak, aby rychle selhala pro efektivní vnitřní smyčku vývoje.
• Jakýkoli jiný přístup, například ChainedTokenCredential nebo ManagedIdentityCredential přímo:

  • Časový interval mezi opakovanými pokusy začíná na 0,8 sekundách a ve výchozím nastavení se pokusí o maximálně pět opakování. Tato možnost je optimalizovaná pro odolnost, ale přináší potenciálně nežádoucí zpoždění ve vnitřní smyčce vývoje.

  • Chcete-li změnit některé z výchozích nastavení opakování, použijte vlastnost Retry v 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),
            }
        };
        ChainedTokenCredential tokenChain = new(
            new ManagedIdentityCredential(miCredentialOptions),
            new VisualStudioCredential()
        );
    

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