Autentisera .NET-appar till Azure-tjänster med hjälp av översikten över Azure Identity-biblioteket
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.
Rekommenderad appautentiseringsmetod
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:
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. |
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_ID och 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. |
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. |
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. |
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 DefaultAzureCredential
lä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.cs
utför du följande steg för att registrera en klientklass och DefaultAzureCredential
:
- Inkludera namnrymderna
Azure.Identity
ochMicrosoft.Extensions.Azure
viausing
direktiv. - Registrera Azure-tjänstklienten med motsvarande
Add
-prefixed extension-metod. - Skicka en instans av
DefaultAzureCredential
till metodenUseCredential
.
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.