Řetězy přihlašovacích údajů v klientské knihovně Azure Identity pro Javu

Článek
11/12/2024

Klientská knihovna Azure Identity poskytuje přihlašovací údaje – veřejné třídy, které implementují rozhraní TokenCredential knihovny Azure Core. Přihlašovací údaje představují jedinečný tok ověřování pro získání přístupového tokenu z ID Microsoft Entra. Tyto přihlašovací údaje je možné zřetězeny dohromady a vytvořit seřazenou posloupnost ověřovacích mechanismů, které se mají pokusit.

Jak funguje zřetězený přihlašovací údaje

Za běhu se řetěz přihlašovacích údajů pokusí ověřit pomocí prvních přihlašovacích údajů sekvence. Pokud se tento přihlašovací údaj nepodaří získat přístupový token, pokusí se další přihlašovací údaje v této sekvenci atd., dokud se přístupový token úspěšně nezíská. Toto chování znázorňuje následující sekvenční diagram:

Diagram znázorňující posloupnost řetězu přihlašovacích údajů

Proč používat řetězy přihlašovacích údajů

Zřetězený přihlašovací údaje můžou nabídnout následující výhody:

Rozpoznávání prostředí: Automaticky vybere nejvhodnější přihlašovací údaje na základě prostředí, ve kterém je aplikace spuštěná. Bez něj byste museli psát kód takto:

import com.azure.core.credential.TokenCredential;
import com.azure.identity.AzureCliCredentialBuilder;
import com.azure.identity.ManagedIdentityCredentialBuilder;

// Code omitted for brevity

TokenCredential credential = null;

// Set up credential based on environment (Azure or local development)
String environment = System.getenv("ENV");

if (environment != null && environment.equals("production")) {
    credential = new ManagedIdentityCredentialBuilder()
        .clientId(userAssignedClientId)
        .build();
} else {
    credential = new AzureCliCredentialBuilder()
        .build();
}

Bezproblémové přechody: Aplikace se může přesunout z místního vývoje do přípravného nebo produkčního prostředí beze změny ověřovacího kódu.
Vylepšená odolnost: Zahrnuje náhradní mechanismus, který se přesune na další přihlašovací údaje, když se předchozí pokus o získání přístupového tokenu nezdaří.

Výběr zřetězených přihlašovacích údajů

Existují dvě různorodé filozofie pro řetězení přihlašovacích údajů:

Použijte předkonfigurovaný řetězec: Začněte s předkonstruovaným řetězem, který vyhovuje nejběžnějším scénářům ověřování. Tento přístup najdete v části s přehledem DefaultAzureCredential.
"Sestavte" řetězec: Začněte prázdným řetězem a zahrňte pouze to, co potřebujete. Tento přístup najdete v části Přehled ChainedTokenCredential.

Přehled defaultAzureCredential

DefaultAzureCredential je předkonfigurovaný řetězec přihlašovacích údajů. Je navržená tak, aby podporovala mnoho prostředí spolu s nejběžnějšími toky ověřování a vývojářskými nástroji. Základní řetězec v grafické podobě vypadá takto:

Pořadí, ve kterém DefaultAzureCredential se pokoušíte o přihlašovací údaje, následuje.

Objednávka	Reference	Popis
1	Prostředí	Načte kolekci proměnných prostředí a určí, jestli je pro aplikaci nakonfigurovaný instanční objekt aplikace (uživatel aplikace). Pokud ano, `DefaultAzureCredential` použije tyto hodnoty k ověření aplikace v Azure. Tato metoda se nejčastěji používá v serverových prostředích, ale dá se použít také při místním vývoji.
2	Identita úloh	Pokud je aplikace nasazená na hostitele Azure s povolenou identitou úloh, ověřte tento účet.
3	Spravovaná identita	Pokud je aplikace nasazená na hostitele Azure s povolenou spravovanou identitou, ověřte ji v Azure pomocí této spravované identity.
4	Mezipaměť sdílených tokenů	Pokud se vývojář ověřil v Azure přihlášením k sadě Visual Studio, ověřte aplikaci do Azure pomocí stejného účtu. (Jenom Windows.)
5	IntelliJ	Pokud se vývojář ověřil prostřednictvím sady Azure Toolkit for IntelliJ, ověřte tento účet.
6	Azure CLI	Pokud se vývojář ověřil v Azure pomocí příkazu Azure CLI `az login` , ověřte aplikaci v Azure pomocí stejného účtu.
7	Azure PowerShell	Pokud se vývojář ověřil v Azure pomocí rutiny Azure PowerShellu `Connect-AzAccount` , ověřte aplikaci v Azure pomocí stejného účtu.
8	Azure Developer CLI	Pokud se vývojář ověřil v Azure pomocí příkazu Azure Developer CLI `azd auth login` , ověřte ho pomocí daného účtu.

V nejjednodušší podobě můžete použít bezparametrovou verzi DefaultAzureCredential následujícím způsobem:

import com.azure.identity.DefaultAzureCredential;
import com.azure.identity.DefaultAzureCredentialBuilder;

// Code omitted for brevity

DefaultAzureCredential credential = new DefaultAzureCredentialBuilder()
    .build();

Přehled ChainedTokenCredential

ChainedTokenCredential je prázdný řetězec, ke kterému přidáváte přihlašovací údaje, které vyhovují potřebám vaší aplikace. Příklad:

import com.azure.identity.AzureCliCredential;
import com.azure.identity.AzureCliCredentialBuilder;
import com.azure.identity.ChainedTokenCredential;
import com.azure.identity.ChainedTokenCredentialBuilder;
import com.azure.identity.ManagedIdentityCredential;
import com.azure.identity.ManagedIdentityCredentialBuilder;

// Code omitted for brevity

ManagedIdentityCredential miCredential = new ManagedIdentityCredentialBuilder()
    .clientId(userAssignedClientId)
    .build();
AzureCliCredential cliCredential = new AzureCliCredentialBuilder()
    .build();

ChainedTokenCredential credential = new ChainedTokenCredentialBuilder()
    .addLast(miCredential)
    .addLast(cliCredential)
    .build();

Předchozí ukázka kódu vytvoří přizpůsobený řetěz přihlašovacích údajů složený ze dvou přihlašovacích údajů. Varianta spravované identity ManagedIdentityCredential přiřazená uživatelem se nejprve pokusí a v případě potřeby následuje AzureCliCredential. V grafické podobě řetězec vypadá takto:

Diagram znázorňující tok ověřování pro instanci ChainedTokenCredential, která se skládá z přihlašovacích údajů spravované identity a přihlašovacích údajů Azure CLI

Tip

Pokud chcete dosáhnout vyššího výkonu, optimalizujte řazení přihlašovacích údajů v ChainedTokenCredential produkčním prostředí. Přihlašovací údaje určené k použití v místním vývojovém prostředí by měly být přidány jako poslední.

Pokyny k použití pro DefaultAzureCredential

DefaultAzureCredential je nepochybně nejjednodušší způsob, jak začít s klientskou knihovnou Azure Identity, ale s tímto pohodlím přichází kompromisy. Po nasazení aplikace do Azure byste měli porozumět požadavkům na ověřování aplikace. Z tohoto důvodu důrazně zvažte přechod z DefaultAzureCredential jednoho z následujících řešení:

Konkrétní implementace přihlašovacích údajů, například ManagedIdentityCredential.
Pared-down ChainedTokenCredential implementace optimalizovaná pro prostředí Azure, ve kterém vaše aplikace běží.

Tady je důvod:

Problémy s laděním: Při selhání ověřování může být náročné ladit a identifikovat odsunuté přihlašovací údaje. Abyste viděli průběh z jednoho pověření na další a stav úspěchu/selhání každého z nich, musíte povolit protokolování. Další informace najdete v tématu Ladění zřetězených přihlašovacích údajů.
Režie na výkon: Proces postupného pokusu o více přihlašovacích údajů může představovat režii na výkon. Například při spuštění na místním vývojovém počítači není spravovaná identita k dispozici. V důsledku toho ManagedIdentityCredential vždy selže v místním vývojovém prostředí.
Nepředvídatelné chování: DefaultAzureCredential kontroluje přítomnost určitých proměnných prostředí. Je možné, že někdo může přidat nebo upravit tyto proměnné prostředí na úrovni systému na hostitelském počítači. Tyto změny platí globálně a proto mění chování DefaultAzureCredential za běhu v libovolné aplikaci spuštěné na tomto počítači.

Ladění zřetězených přihlašovacích údajů

Pokud chcete diagnostikovat neočekávaný problém nebo zjistit, co dělá zřetězený přihlašovací údaj, povolte protokolování v aplikaci.

Pro ilustraci předpokládejme, že se k ověření požadavku na účet Blob Storage používá bez DefaultAzureCredential parametrů. Aplikace běží v místním vývojovém prostředí a vývojář se ověřil v Azure pomocí Azure CLI. Při spuštění aplikace se ve výstupu zobrazí následující relevantní položky:

[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential EnvironmentCredential is unavailable.
[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential WorkloadIdentityCredential is unavailable.
[ForkJoinPool.commonPool-worker-1] WARN com.microsoft.aad.msal4j.ConfidentialClientApplication - [Correlation ID: aaaa0000-bb11-2222-33cc-444444dddddd] Execution of class com.microsoft.aad.msal4j.AcquireTokenByClientCredentialSupplier failed: java.util.concurrent.ExecutionException: com.azure.identity.CredentialUnavailableException: ManagedIdentityCredential authentication unavailable. Connection to IMDS endpoint cannot be established.
[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential ManagedIdentityCredential is unavailable.
[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential SharedTokenCacheCredential is unavailable.
[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential IntelliJCredential is unavailable.
[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential AzureCliCredential returns a token

V předchozím výstupu si všimněte, že:

EnvironmentCredential, WorkloadIdentityCredential, ManagedIdentityCredentialSharedTokenCacheCredentiala IntelliJCredential každý z nich se nepodařilo získat přístupový token Microsoft Entra v daném pořadí.
Volání AzureCliCredential.getToken proběhne úspěšně, jak je uvedeno v returns a tokenpoložce -suffixed. Od té doby, co AzureCliCredential bylo úspěšné, se nepoužily žádné přihlašovací údaje.

Sdílet prostřednictvím