Dela via

Autentisera .NET-appar till Azure-tjänster med hjälp av översikten över Azure Identity-biblioteket

  • Artikel

När en app behöver åtkomst till en Azure-resurs måste appen autentiseras till Azure. Detta gäller för alla appar, oavsett om de distribueras till Azure, distribueras lokalt eller under utveckling på en lokal arbetsstation för utvecklare. Den här artikeln beskriver de rekommenderade metoderna för att autentisera en app till Azure när du använder Azure SDK-klientbibliotek.

Vi rekommenderar att appar använder tokenbaserad autentisering i stället för anslutningssträngar vid autentisering till Azure-resurser. Azure Identity-biblioteket innehåller klasser som stöder tokenbaserad autentisering och gör det möjligt för appar att smidigt autentisera till Azure-resurser oavsett om appen är i lokal utveckling, distribueras till Azure eller distribueras till en lokal server.

Den specifika typen av tokenbaserad autentisering som en app ska använda för att autentisera till Azure-resurser beror på var appen körs och visas i följande diagram:

Ett diagram som visar de rekommenderade tokenbaserade autentiseringsstrategierna för en app beroende på var den körs.

När en app är:

  • När den körs lokalt under utvecklingkan appen autentisera sig mot Azure antingen med applikationens tjänsthuvudnamn för lokal utveckling eller med hjälp av utvecklarens Azure-autentiseringsuppgifter. Varje alternativ diskuteras mer detaljerat under autentisering under lokal utveckling.
  • värd på Azurebör appen autentisera mot Azure-resurser med hjälp av en hanterad identitet. Det här alternativet beskrivs mer detaljerat vid autentisering i servermiljöer.
  • Värd och distribuerad lokaltbör appen autentisera mot Azure-resurser med hjälp av ett applikationshuvudnamn. Det här alternativet beskrivs mer detaljerat vid autentisering i servermiljöer.

StandardAzureCredential

Klassen DefaultAzureCredential som tillhandahålls av Azure Identity-biblioteket gör att appar kan använda olika autentiseringsmetoder beroende på vilken miljö de körs i. Detta gör att appar kan höjas upp från lokal utveckling till att testa miljöer till produktion utan kodändringar. Du konfigurerar lämplig autentiseringsmetod för varje miljö och DefaultAzureCredential identifierar och använder den autentiseringsmetoden automatiskt. Användning av DefaultAzureCredential bör föredras framför att manuellt koda villkorslogik eller funktionsflaggor för att använda olika autentiseringsmetoder i olika miljöer.

Information om hur du använder DefaultAzureCredential beskrivs i Använd DefaultAzureCredential i ett program.

Fördelar med tokenbaserad autentisering

Tokenbaserad autentisering ger följande fördelar jämfört med autentisering med anslutningssträngar:

  • Med de tokenbaserade autentiseringsmetoder som beskrivs nedan kan du upprätta de specifika behörigheter som krävs av appen för Azure-resursen. Detta följer -principen om lägsta behörighet. En anslutningssträng ger däremot fullständig behörighet till Azure-resursen.
  • Medan alla eller appar med en anslutningssträng kan ansluta till en Azure-resurs, begränsar tokenbaserade autentiseringsmetoder åtkomst till resursen till endast de appar som är avsedda att komma åt den.
  • När det gäller en hanterad identitet finns det ingen programhemlighet att lagra. Detta gör appen säkrare eftersom det inte finns någon anslutningssträng eller programhemlighet som kan komprometteras.
  • Paketet Azure.Identity hämtar och hanterar Microsoft Entra-token åt dig. Detta gör det enkelt att använda tokenbaserad autentisering som en anslutningssträng.

Användning av anslutningssträngar bör begränsas till inledande proof-of-concept-appar eller utvecklingsprototyper som inte har åtkomst till produktionsdata eller känsliga data. Annars bör de tokenbaserade autentiseringsklasserna som är tillgängliga i Azure Identity-biblioteket alltid föredras när du autentiserar till Azure-resurser.

Autentisering i servermiljöer

När du är värd för en servermiljö ska varje app tilldelas en unik programidentitet per miljö där appen körs. I Azure representeras en programidentitet av ett tjänstens huvudnamn, en särskild typ av säkerhetsobjekt avsedd att identifiera och autentisera appar till Azure. Vilken typ av tjänsthuvudnamn som ska användas för din app beror på var appen körs.

Autentiseringsmetod Beskrivning
Appar som finns i Azure Appar som finns i Azure bör använda tjänstens huvudnamn för hanterad identitet. Hanterade identiteter är utformade för att representera identiteten för en app som finns i Azure och kan endast användas med Azure-värdbaserade appar.

Till exempel skulle en .NET-webbapp som finns i Azure App Service tilldelas en hanterad identitet. Den hanterade identitet som tilldelats appen används sedan för att autentisera appen till andra Azure-tjänster.

Läs mer om autentisering i applikationer som är värdade av Azure
Appar som finns utanför Azure
(till exempel lokala appar)		 Appar som finns utanför Azure (till exempel lokala appar) som behöver ansluta till Azure-tjänster bör använda ett application service principal. Ett huvudnamn för programtjänsten representerar appens identitet i Azure och skapas via programregistreringsprocessen.

Tänk dig till exempel en .NET-webbapp som finns lokalt och som använder Azure Blob Storage. Du skapar ett programtjänsthuvudnamn för appen med hjälp av appregistreringsprocessen. AZURE_CLIENT_ID, AZURE_TENANT_IDoch AZURE_CLIENT_SECRET skulle alla lagras som miljövariabler för att läsas av programmet vid körning och så att appen kan autentisera mot Azure med hjälp av tjänsthuvudnamnet för applikationstjänsten.

Läs mer om autentisering från appar som finns utanför Azure

Autentisering under lokal utveckling

När en app körs på en utvecklares arbetsstation under den lokala utvecklingen måste den fortfarande autentiseras mot alla Azure-tjänster som används av appen. De två huvudsakliga strategierna för att autentisera appar till Azure under lokal utveckling är:

Autentiseringsmetod Beskrivning
Skapa dedikerade huvudobjekt för programtjänsten som ska användas under lokal utveckling I den här metoden konfigureras dedikerade programtjänstens huvudnamn objekt med hjälp av appregistreringsprocessen för användning under lokal utveckling. Identiteten för tjänstens huvudnamn lagras sedan som miljövariabler som ska användas av appen när den körs i lokal utveckling.

Med den här metoden kan du tilldela de specifika resursbehörigheter som krävs av appen till de objekt för tjänstens huvudnamn som används av utvecklare under den lokala utvecklingen. Detta säkerställer att programmet bara har åtkomst till de specifika resurser som behövs och replikerar de behörigheter som appen kommer att ha i produktion.

Nackdelen med den här metoden är behovet av att skapa separata servicehuvudsobjekt för varje utvecklare som arbetar med en applikation.

Läs mer om autentisering i applikationer som är värdade av Azure
Autentisera appen till Azure med utvecklarens autentiseringsuppgifter under den lokala utvecklingen I den här metoden måste en utvecklare loggas in på Azure från antingen Visual Studio, Azure Tools-tillägget för VS Code, Azure CLI eller Azure PowerShell på sin lokala arbetsstation. Programmet kan sedan komma åt utvecklarens autentiseringsuppgifter från autentiseringsarkivet och använda dessa autentiseringsuppgifter för att komma åt Azure-resurser från appen.

Den här metoden har fördelen med enklare konfiguration eftersom en utvecklare bara behöver logga in på sitt Azure-konto från Visual Studio, VS Code eller Azure CLI. Nackdelen med den här metoden är att utvecklarkontot sannolikt har fler behörigheter än vad som krävs av programmet. Den här metoden replikerar därför inte korrekt de behörigheter som appen ska köras med i produktion.

Läs mer om autentisering i applikationer som är värdade av Azure

Använda DefaultAzureCredential i ett program

DefaultAzureCredential är en åsiktsbaserad, ordnad sekvens med mekanismer för autentisering till Microsoft Entra-ID. Varje autentiseringsmekanism är en klass som härleds från klassen TokenCredential och kallas autentiseringsuppgifter. Vid körning försöker DefaultAzureCredential autentisera med hjälp av den första autentiseringsuppgiften. Om autentiseringen misslyckas med att hämta en åtkomsttoken, testas nästa autentiseringsuppgifterna i sekvensen, och så fortsätter det tills en åtkomsttoken har hämtats. På så sätt kan din app använda olika autentiseringsuppgifter i olika miljöer utan att skriva miljöspecifik kod.

Om du vill använda DefaultAzureCredentiallägger du till Azure.Identity- och eventuellt paketen Microsoft.Extensions.Azure i ditt program:

I valfri terminal går du till programprojektkatalogen och kör följande kommandon:

dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure

Azure-tjänster används med hjälp av specialiserade klientklasser från de olika Azure SDK-klientbiblioteken. Dessa klasser och dina egna anpassade tjänster bör registreras så att de kan nås via beroendeinmatning i hela appen. I Program.csutför du följande steg för att registrera en klientklass och DefaultAzureCredential:

  1. Inkludera namnrymderna Azure.Identity och Microsoft.Extensions.Azure via using direktiv.
  2. Registrera Azure-tjänstklienten med motsvarande Add-prefixed extension-metod.
  3. Skicka en instans av DefaultAzureCredential till metoden UseCredential.

Till exempel:

using Microsoft.Extensions.Azure;
using Azure.Identity;

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

Ett alternativ till UseCredential är att instansiera DefaultAzureCredential direkt:

using Azure.Identity;

builder.Services.AddSingleton<BlobServiceClient>(_ =>
    new BlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"),
        new DefaultAzureCredential()));

När föregående kod körs på din lokala utvecklingsarbetsstation letar den i miljövariablerna efter ett huvudnamn för programtjänsten eller lokalt installerade utvecklarverktyg, till exempel Visual Studio, för en uppsättning autentiseringsuppgifter för utvecklare. Endera metoden kan användas för att autentisera appen till Azure-resurser under lokal utveckling.

När den distribueras till Azure kan samma kod även autentisera din app till andra Azure-resurser. DefaultAzureCredential kan hämta miljöinställningar och hanterade identitetskonfigurationer för att autentisera till andra tjänster automatiskt.