Delen via

.NET-apps verifiëren bij Azure-services met behulp van het overzicht van de Azure Identity-bibliotheek

  • Artikel

Wanneer een app toegang moet hebben tot een Azure-resource, moet de app worden geverifieerd bij Azure. Dit geldt voor alle apps, ongeacht of deze zijn geïmplementeerd in Azure, on-premises zijn geïmplementeerd of in ontwikkeling zijn op een lokaal ontwikkelwerkstation. In dit artikel worden de aanbevolen methoden beschreven voor het verifiëren van een app bij Azure bij het gebruik van de Azure SDK-clientbibliotheken.

Het wordt aanbevolen dat apps gebruikmaken van verificatie op basis van tokens in plaats van verbindingsreeksen bij het verifiëren van Azure-resources. De Azure Identity-bibliotheek biedt klassen die ondersteuning bieden voor verificatie op basis van tokens en waarmee apps naadloos kunnen worden geverifieerd bij Azure-resources, ongeacht of de app zich in lokale ontwikkeling bevindt, in Azure is geïmplementeerd of op een on-premises server is geïmplementeerd.

Het specifieke type verificatie op basis van tokens dat een app moet gebruiken om te verifiëren bij Azure-resources, is afhankelijk van waar de app wordt uitgevoerd en wordt weergegeven in het volgende diagram:

een diagram met de aanbevolen verificatiestrategieën op basis van tokens voor een app, afhankelijk van waar deze wordt uitgevoerd.

Wanneer een app:

  • Lokaal draaien tijdens de ontwikkeling, kan de app zich authenticeren bij Azure met behulp van een service-principal voor lokale ontwikkeling of met behulp van de Azure-referenties van de ontwikkelaar. Elke optie wordt uitvoeriger besproken bij authenticatie tijdens lokale ontwikkeling.
  • Gehost op Azure, moet de app zich authenticeren bij Azure-resources met behulp van een beheerde identiteit. Deze optie wordt uitvoeriger besproken bij verificatie in serveromgevingen.
  • gehost en geïmplementeerd on-premises, dient de app te worden geverifieerd bij Azure-resources met behulp van een applicatie-serviceprincipal. Deze optie wordt uitvoeriger besproken bij verificatie in serveromgevingen.

DefaultAzureCredential

Met de DefaultAzureCredential-klasse die wordt geleverd door de Azure Identity-bibliotheek, kunnen apps verschillende verificatiemethoden gebruiken, afhankelijk van de omgeving waarin ze worden uitgevoerd. Hierdoor kunnen apps gepromoveerd worden van lokale ontwikkeling naar testomgevingen en vervolgens naar productie zonder codewijzigingen. U configureert de juiste verificatiemethode voor elke omgeving en DefaultAzureCredential detecteert en gebruikt deze verificatiemethode automatisch. Het gebruik van DefaultAzureCredential moet de voorkeur hebben boven het handmatig coderen van voorwaardelijke logica of functievlagmen om verschillende verificatiemethoden in verschillende omgevingen te gebruiken.

Meer informatie over het gebruik van DefaultAzureCredential vindt u in Gebruik DefaultAzureCredential in een toepassing.

Voordelen van verificatie op basis van tokens

Verificatie op basis van tokens biedt de volgende voordelen ten opzichte van verificatie met verbindingsreeksen:

  • Met de verificatiemethoden op basis van tokens die hieronder worden beschreven, kunt u de specifieke machtigingen instellen die nodig zijn voor de app in de Azure-resource. Dit volgt het principe van minimale bevoegdheden. Een verbindingsreeks verleent daarentegen volledige rechten aan de Azure-resource.
  • Terwijl daarentegen iedereen of elke app met een connectiestring verbinding kan maken met een Azure-resource, beperken token-gebaseerde authenticatiemethoden de toegang tot de resource tot alleen de app(s) die bedoeld zijn om toegang tot de resource te hebben.
  • In het geval van een beheerde identiteit is er geen toepassingsgeheim om op te slaan. Hierdoor is de app veiliger omdat er geen verbindingsreeks of toepassingsgeheim is dat kan worden aangetast.
  • Het Azure.Identity-pakket verkrijgt en beheert Microsoft Entra-tokens voor u. Dit maakt het gebruik van verificatie op basis van tokens net zo eenvoudig als een verbindingsreeks.

Het gebruik van verbindingsreeksen moet worden beperkt tot initiële proof-of-concept-apps of prototypen voor ontwikkeling die geen toegang hebben tot productie- of gevoelige gegevens. Anders moeten de verificatieklassen op basis van tokens die beschikbaar zijn in de Azure Identity-bibliotheek altijd de voorkeur krijgen bij het verifiëren bij Azure-resources.

Verificatie in serveromgevingen

Bij het hosten in een serveromgeving moet aan elke app een unieke toepassingsidentiteit worden toegewezen per omgeving waarin de app wordt uitgevoerd. In Azure wordt een toepassingsidentiteit vertegenwoordigd door een service-principal, een speciaal type beveiligingsprincipaal bedoeld om apps te identificeren en te verifiëren bij Azure. Het type service-principal dat voor uw app moet worden gebruikt, is afhankelijk van de locatie waarop uw app wordt uitgevoerd.

Verificatiemethode Beschrijving
Apps die worden gehost in Azure Apps die worden gehost in Azure, moeten gebruikmaken van een Managed Identity-service-principal. Beheerde identiteiten zijn ontworpen om de identiteit van een app te vertegenwoordigen die wordt gehost in Azure en kan alleen worden gebruikt met door Azure gehoste apps.

Aan een .NET-web-app die wordt gehost in Azure App Service, wordt bijvoorbeeld een beheerde identiteit toegewezen. De beheerde identiteit die aan de app is toegewezen, wordt vervolgens gebruikt om de app te verifiëren bij andere Azure-services.

Meer informatie over verificatie vanuit door Azure gehoste apps
Apps die buiten Azure worden gehost
(bijvoorbeeld on-premises apps)		 Apps die buiten Azure worden gehost (bijvoorbeeld on-premises apps) die verbinding moeten maken met Azure-services, moeten gebruikmaken van een application-service-principal. Een toepassingsservice-principal vertegenwoordigt de identiteit van de app in Azure en wordt gemaakt via het registratieproces van de toepassing.

Denk bijvoorbeeld aan een .NET-web-app die on-premises wordt gehost en die gebruikmaakt van Azure Blob Storage. U maakt een toepassingsservice-principal voor de app met behulp van het app-registratieproces. De AZURE_CLIENT_ID, AZURE_TENANT_IDen AZURE_CLIENT_SECRET worden allemaal opgeslagen als omgevingsvariabelen die tijdens runtime door de toepassing moeten worden gelezen en waarmee de app kan worden geverifieerd bij Azure met behulp van de service-principal van de toepassing.

Meer informatie over verificatie van apps die buiten Azure worden gehost

Verificatie tijdens lokale ontwikkeling

Wanneer een app wordt uitgevoerd op het werkstation van een ontwikkelaar tijdens de lokale ontwikkeling, moet deze nog steeds worden geverifieerd bij alle Azure-services die door de app worden gebruikt. De twee belangrijkste strategieën voor het verifiëren van apps bij Azure tijdens lokale ontwikkeling zijn:

Verificatiemethode Beschrijving
Maak speciale service-principalobjecten voor applicaties die tijdens lokale ontwikkeling moeten worden gebruikt. In deze methode worden toegewezen applicatieservice-principal-objecten ingesteld met behulp van het app-registratieproces voor gebruik tijdens lokale ontwikkeling. De identiteit van de service-principal wordt vervolgens opgeslagen als omgevingsvariabelen die toegankelijk zijn voor de app wanneer deze wordt uitgevoerd in lokale ontwikkeling.

Met deze methode kunt u de specifieke resourcemachtigingen die de app nodig heeft, toewijzen aan de service-principal-objecten die tijdens de lokale ontwikkeling door ontwikkelaars worden gebruikt. Dit zorgt ervoor dat de toepassing alleen toegang heeft tot de specifieke resources die deze nodig heeft en repliceert de machtigingen die de app in productie heeft.

Het nadeel van deze aanpak is dat er afzonderlijke service-principalobjecten moeten worden gemaakt voor elke ontwikkelaar die in een toepassing werkt.

Meer informatie over verificatie vanuit door Azure gehoste apps
De app verifiëren bij Azure met behulp van de referenties van de ontwikkelaar tijdens lokale ontwikkeling In deze methode moet een ontwikkelaar zijn aangemeld bij Azure vanuit Visual Studio, de Azure Tools-extensie voor VS Code, de Azure CLI of Azure PowerShell op hun lokale werkstation. De toepassing heeft vervolgens toegang tot de referenties van de ontwikkelaar vanuit het referentiearchief en gebruikt deze referenties voor toegang tot Azure-resources vanuit de app.

Deze methode heeft het voordeel van een eenvoudigere installatie, omdat een ontwikkelaar zich alleen hoeft aan te melden bij hun Azure-account vanuit Visual Studio, VS Code of de Azure CLI. Het nadeel van deze benadering is dat het account van de ontwikkelaar waarschijnlijk meer machtigingen heeft dan vereist is voor de toepassing. Daarom repliceert deze methode niet nauwkeurig de machtigingen waarmee de app wordt uitgevoerd in productie.

Meer informatie over verificatie vanuit door Azure gehoste apps

DefaultAzureCredential gebruiken in een toepassing

DefaultAzureCredential is een overtuigde, geordende volgorde van mechanismen voor verificatie bij Microsoft Entra ID. Elk verificatiemechanisme is een klasse die is afgeleid van de TokenCredential-klasse en wordt een referentiegenoemd. Tijdens runtime probeert DefaultAzureCredential te verifiëren met behulp van de eerste referentie. Als deze referentie geen toegangstoken kan verkrijgen, wordt de volgende referentie in de reeks geprobeerd, enzovoort, totdat een toegangstoken is verkregen. Op deze manier kan uw app verschillende referenties in verschillende omgevingen gebruiken zonder omgevingsspecifieke code te schrijven.

Als u DefaultAzureCredentialwilt gebruiken, voegt u de Azure.Identity- en eventueel de Microsoft.Extensions.Azure-pakketten toe aan uw toepassing:

Navigeer in een terminal van uw keuze naar de projectmap van de toepassing en voer de volgende opdrachten uit:

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

Azure-services worden geopend met behulp van gespecialiseerde clientklassen uit de verschillende Azure SDK-clientbibliotheken. Deze klassen en uw eigen aangepaste services moeten worden geregistreerd, zodat ze kunnen worden geopend via afhankelijkheidsinjectie in uw app. Voer in Program.csde volgende stappen uit om een clientklasse en DefaultAzureCredentialte registreren:

  1. Neem de Azure.Identity en Microsoft.Extensions.Azure naamruimten op via using instructies.
  2. Registreer de Azure-serviceclient met behulp van de bijbehorende Add-voorvoegselextensiemethode.
  3. Geef een exemplaar van DefaultAzureCredential door aan de methode UseCredential.

Bijvoorbeeld:

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

Een alternatief voor UseCredential is het rechtstreeks instantiëren van DefaultAzureCredential:

using Azure.Identity;

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

Wanneer de voorgaande code wordt uitgevoerd op uw lokale ontwikkelwerkstation, wordt er gezocht in de omgevingsvariabelen voor een toepassingsservice-principal of in lokaal geïnstalleerde ontwikkelhulpprogramma's, zoals Visual Studio, voor een set ontwikkelaarsreferenties. Beide benaderingen kunnen worden gebruikt om de app te verifiëren bij Azure-resources tijdens lokale ontwikkeling.

Wanneer deze code wordt geïmplementeerd in Azure, kan dezelfde code uw app ook verifiëren bij andere Azure-resources. DefaultAzureCredential kunt omgevingsinstellingen en beheerde identiteitsconfiguraties ophalen om automatisch te verifiëren bij andere services.