Autentiseringskedjor i Azure Identity-klientbiblioteket för Java

Azure Identity-klientbiblioteket innehåller autentiseringsuppgifter – offentliga klasser som implementerar Azure Core-bibliotekets TokenCredential-gränssnitt . En autentiseringsuppgift representerar ett distinkt autentiseringsflöde för att hämta en åtkomsttoken från Microsoft Entra-ID. Dessa autentiseringsuppgifter kan kopplas samman för att bilda en ordnad sekvens med autentiseringsmekanismer som ska försökas.

Så här fungerar en länkad autentiseringsuppgift

Vid körning försöker en autentiseringskedja autentisera med sekvensens första autentiseringsuppgifter. Om det inte går att hämta en åtkomsttoken görs nästa autentiseringsuppgifter i sekvensen och så vidare tills en åtkomsttoken har hämtats. Följande sekvensdiagram illustrerar det här beteendet:

Varför använda autentiseringskedjor

En länkad autentiseringsuppgift kan erbjuda följande fördelar:

• Miljömedvetenhet: Väljer automatiskt de lämpligaste autentiseringsuppgifterna baserat på miljön där appen körs. Utan den skulle du behöva skriva kod så här:

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

• Sömlösa övergångar: Din app kan gå från lokal utveckling till mellanlagrings- eller produktionsmiljön utan att ändra autentiseringskoden.

• Förbättrad återhämtning: Innehåller en återställningsmekanism som flyttas till nästa autentiseringsuppgift när den föregående misslyckas med att hämta en åtkomsttoken.

Så här väljer du en länkad autentiseringsuppgift

Det finns två olika filosofier för autentiseringslänkning:

• Använd en förkonfigurerad kedja: Börja med en åsiktsbaserad, förkonstruerad kedja som rymmer de vanligaste autentiseringsscenarierna. För den här metoden kan du läsa översiktsavsnittet DefaultAzureCredential.
• "Bygg upp" en kedja: Börja med en tom kedja och inkludera bara det du behöver. Den här metoden finns i översiktsavsnittet ChainedTokenCredential.

Översikt över DefaultAzureCredential

DefaultAzureCredential är en åsiktsbaserad, förkonfigurerad kedja med autentiseringsuppgifter. Den är utformad för att stödja många miljöer, tillsammans med de vanligaste autentiseringsflödena och utvecklarverktygen. I grafisk form ser den underliggande kedjan ut så här:

Den ordning som DefaultAzureCredential autentiseringsförsöken följer.

I sin enklaste form kan du använda den parameterlösa versionen av DefaultAzureCredential på följande sätt:

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

// Code omitted for brevity

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

Översikt över ChainedTokenCredential

ChainedTokenCredential är en tom kedja som du lägger till autentiseringsuppgifter till för att passa appens behov. Till exempel:

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

Föregående kodexempel skapar en anpassad autentiseringskedja som består av två autentiseringsuppgifter. Den användartilldelade hanterade identitetsvarianten för ManagedIdentityCredential görs först, följt av AzureCliCredential, om det behövs. I grafisk form ser kedjan ut så här:

Användningsvägledning för DefaultAzureCredential

DefaultAzureCredential är utan tvekan det enklaste sättet att komma igång med Azure Identity-klientbiblioteket, men med den bekvämligheten kommer kompromisser. När du har distribuerat din app till Azure bör du förstå appens autentiseringskrav. Därför bör du överväga att flytta från DefaultAzureCredential till någon av följande lösningar:

• En specifik implementering av autentiseringsuppgifter, till exempel ManagedIdentityCredential.
• En avskalad implementering optimerad för Azure-miljön ChainedTokenCredential där appen körs.

Här är varför:

• Felsökningsutmaningar: När autentiseringen misslyckas kan det vara svårt att felsöka och identifiera de felaktiga autentiseringsuppgifterna. Du måste aktivera loggning för att se förloppet från en autentiseringsuppgift till nästa och statusen för lyckade/misslyckade för var och en. Mer information finns i Felsöka en länkad autentiseringsuppgift.
• Prestandakostnader: Processen med att sekventiellt prova flera autentiseringsuppgifter kan medföra prestandakostnader. När den till exempel körs på en lokal utvecklingsdator är den hanterade identiteten inte tillgänglig. Därför ManagedIdentityCredential misslyckas alltid i den lokala utvecklingsmiljön.
• Oförutsägbart beteende: DefaultAzureCredential söker efter förekomsten av vissa miljövariabler. Det är möjligt att någon kan lägga till eller ändra dessa miljövariabler på systemnivå på värddatorn. Dessa ändringar gäller globalt och ändrar därför beteendet DefaultAzureCredential för vid körning i alla appar som körs på den datorn.

Felsöka en länkad autentiseringsuppgift

Om du vill diagnostisera ett oväntat problem eller förstå vad en länkad autentiseringsuppgift gör aktiverar du loggning i din app.

I illustrationssyfte förutsätter vi att den parameterlösa formen av DefaultAzureCredential används för att autentisera en begäran till ett Blob Storage-konto. Appen körs i den lokala utvecklingsmiljön och utvecklaren autentiseras till Azure med hjälp av Azure CLI. När appen körs visas följande relevanta poster i utdata:

[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

Observera följande i föregående utdata:

• EnvironmentCredential, WorkloadIdentityCredential, ManagedIdentityCredential, SharedTokenCacheCredentialoch var och IntelliJCredential en kunde inte hämta en Microsoft Entra-åtkomsttoken i den ordningen.
• Anropet AzureCliCredential.getToken lyckas enligt - returns a tokensuffixed-posten. Sedan AzureCliCredential lyckades har inga autentiseringsuppgifter utöver det prövats.