Dela via


Autentiseringskedjor i Azure Identity-klientbiblioteket för Go

Azure Identity-klientbiblioteket innehåller autentiseringsuppgifter– offentliga typer 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 prövas nästa autentiseringsuppgift i sekvensen och så vidare tills en åtkomsttoken har hämtats. Följande sekvensdiagram illustrerar det här beteendet:

diagram som visar autentiseringskedjans sekvens.

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:

    // Set up credential based on environment (Azure or local development)
    if os.Getenv("WEBSITE_HOSTNAME") != "" {
        clientID := azidentity.ClientID("abcd1234-...")
        opts := azidentity.ManagedIdentityCredentialOptions{ID: clientID}
        cred, err := azidentity.NewManagedIdentityCredential(&opts)
    
        if err != nil {
          // TODO: handle error
        }
    }
    else {
        // Use Azure CLI Credential
        credential, err = azidentity.NewAzureCLICredential(nil)
    
        if err != nil {
          // TODO: handle error
        }
    }
    
  • Sömlösa övergångar: Appen 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

Med Go finns det två alternativ för autentiseringskedja:

  • Använd en förkonfigurerad kedja: Använd den förkonfigurerade kedjan som implementeras av DefaultAzureCredential typ. För denna metod, se avsnittet DefaultAzureCredential-översikt.
  • Skapa en anpassad autentiseringskedja: Börja med en tom kedja och inkludera bara det du behöver. Den här metoden finns i översikten ChainedTokenCredential.

Översikt över DefaultAzureCredential

DefaultAzureCredential är en åsiktsbaserad, förkonfigurerad kedja av 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:

diagram som visar autentiseringsflödet DefaultAzureCredential.

I vilken ordning DefaultAzureCredential försöker autentisera följs.

Beställning Behörighet Beskrivning
1 Miljö Läser en samling miljövariabler för att avgöra om ett programtjänsthuvudnamn (programanvändare) har konfigurerats för appen. I så fall använder DefaultAzureCredential dessa värden för att autentisera appen till Azure. Den här metoden används oftast i servermiljöer men kan också användas när du utvecklar lokalt.
2 arbetsbelastningsidentitet Om appen distribueras till en Azure-värd med arbetsbelastningsidentitet aktiverad autentiserar du kontot.
3 Hanterad identitet för Azure Om appen distribueras till en Azure-värd med hanterad identitet aktiverad autentiserar du appen till Azure med hjälp av den hanterade identiteten.
4 Azure CLI Om utvecklaren autentiserades till Azure med hjälp av Azure CLI:s az login-kommando autentiserar du appen till Azure med samma konto.
5 Azure Developer CLI Om utvecklaren autentiserade till Azure med hjälp av Azure Developer CLI:s azd auth login-kommando autentiserar du med det kontot.

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

import (
    "github.com/Azure/azure-sdk-for-go/sdk/azidentity"
    "github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
    )

// create a credential
credential, err := azidentity.NewDefaultAzureCredential(nil)
if err != nil {
    // TODO: handle error
}

// create a Blob service client 
accountURL := "https://<my_account_name>.blob.core.windows.net"
client, err := azblob.NewClient(accountURL, credential, nil)
if err != nil {
    // TODO: handle error
}

Översikt över ChainedTokenCredential

ChainedTokenCredential är en tom kedja där du lägger till autentiseringsuppgifter som passar appens behov. Till exempel:

managed, err := azidentity.NewManagedIdentityCredential(nil)
if err != nil {
  // handle error
}

azCLI, err := azidentity.NewAzureCLICredential(nil)
if err != nil {
  // handle error
}

chain, err := azidentity.NewChainedTokenCredential([]azcore.TokenCredential{managed, azCLI}, nil)
if err != nil {
  // handle error
}

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

diagram som visar autentiseringsflödet för en ChainedTokenCredential-instans som består av hanterade identitetsautentiseringsuppgifter och Azure CLI-autentiseringsuppgifter.

Tips

Optimera ordning på autentiseringsuppgifter i ChainedTokenCredential för produktionsmiljön för bättre prestanda. Autentiseringsuppgifter som är avsedda att användas i den lokala utvecklingsmiljön bör läggas till sist.

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 ChainedTokenCredential implementering optimerad för Azure-miljön 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 misslyckas ManagedIdentityCredential alltid i den lokala utvecklingsmiljön, såvida den inte uttryckligen inaktiveras via motsvarande exclude-prefixed-egenskap.
  • 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 för DefaultAzureCredential vid körning i alla appar som körs på den datorn.

Felsöka en länkad autentiseringsuppgift

För att diagnostisera ett oväntat problem eller förstå vad en kedjad autentisering gör, aktivera loggning i din app. Du kan också filtrera loggarna till endast de händelser som genereras från Azure Identity-klientbiblioteket. Till exempel:

import azlog "github.com/Azure/azure-sdk-for-go/sdk/azcore/log"
// print log output to stdout
azlog.SetListener(func(event azlog.Event, s string) {
    fmt.Println(s)
})
// include only azidentity credential logs
azlog.SetEvents(azidentity.EventAuthentication)

Information om hur du löser fel från specifika typer av autentiseringsuppgifter finns i felsökningsguiden för .