.NET-apps verifiëren bij Azure-services met behulp van de .NET Azure SDK

Wanneer een toepassing toegang moet hebben tot een Azure-resource, zoals opslag, sleutelkluis of cognitive services, moet de toepassing worden geverifieerd bij Azure. Dit geldt voor alle toepassingen, 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 wanneer u de Azure SDK voor .NET gebruikt.

Aanbevolen methode voor app-verificatie

Het wordt aanbevolen dat apps gebruikmaken van verificatie op basis van tokens in plaats van verbindingsreeks s bij het verifiëren bij Azure-resources. De Azure SDK voor .NET 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.

• Wanneer een ontwikkelaar een app uitvoert tijdens lokale ontwikkeling: de app kan worden geverifieerd bij Azure met behulp van een toepassingsservice-principal voor lokale ontwikkeling of met behulp van de Azure-referenties van de ontwikkelaar. Elk van deze opties wordt uitvoeriger besproken in de sectieverificatie tijdens lokale ontwikkeling.
• Wanneer een app wordt gehost in Azure: de app moet worden geverifieerd bij Azure-resources met behulp van een beheerde identiteit. Deze optie wordt hieronder uitgebreid besproken in de sectieverificatie in serveromgevingen.
• Wanneer een app on-premises wordt gehost en geïmplementeerd: de app moet worden geverifieerd bij Azure-resources met behulp van een service-principal voor toepassingen. Deze optie wordt hieronder uitgebreid besproken in de sectieverificatie in serveromgevingen.

DefaultAzureCredential

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

Meer informatie over het gebruik van de DefaultAzureCredential klasse vindt u verderop in dit artikel in de sectie Gebruiken DefaultAzureCredential in een toepassing.

Voordelen van verificatie op basis van tokens

Verificatie op basis van tokens wordt sterk aangeraden om verbindingsreeks s te gebruiken bij het bouwen van apps voor Azure. Verificatie op basis van tokens biedt de volgende voordelen ten opzichte van verificatie met verbindingsreeks s.

• 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 iedereen of elke app met een verbindingsreeks verbinding kan maken met een Azure-resource, hebben tokengebaseerde verificatiemethoden toegang tot de resource tot alleen de app(s) die zijn bedoeld voor toegang tot de resource.
• 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 dan kan worden aangetast.
• Het Pakket Azure.Identity in de Azure SDK beheert tokens voor u achter de schermen. Dit maakt het gebruik van verificatie op basis van tokens net zo eenvoudig als een verbindingsreeks.

Het gebruik van verbindingsreeks s moet worden beperkt tot het eerste bewijs van 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 SDK altijd de voorkeur krijgen bij het verifiëren bij Azure-resources.

Verificatie in serveromgevingen

Bij het hosten in een serveromgeving moet aan elke toepassing een unieke toepassings-id worden toegewezen per omgeving waarin de toepassing wordt uitgevoerd. In Azure wordt een app-identiteit vertegenwoordigd door een service-principal, een speciaal type beveiligingsprincipaal dat is 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 service-principal voor beheerde identiteiten. 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. 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 toepassingsservice-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 toestaan dat de app wordt 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 toepassing 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
Toegewezen toepassingsservice-principalobjecten maken die moeten worden gebruikt tijdens lokale ontwikkeling	In deze methode worden toegewezen service-principalobjecten voor toepassingen 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 ondersteunt meerdere verificatiemethoden en bepaalt de verificatiemethode die tijdens runtime wordt gebruikt. Op deze manier kan uw app verschillende verificatiemethoden in verschillende omgevingen gebruiken zonder omgevingsspecifieke code te implementeren.

De volgorde en locaties waarin DefaultAzureCredential wordt gezocht naar referenties, vindt u op DefaultAzureCredential.

Als u wilt implementeren DefaultAzureCredential, voegt u eerst de Azure.Identity en eventueel de Microsoft.Extensions.Azure pakketten toe aan uw toepassing. U kunt dit doen met behulp van de opdrachtregel of de NuGet-Pakketbeheer.

Opdrachtregel

Open een terminalomgeving naar keuze in de projectmap van de toepassing en voer de onderstaande opdracht in.

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

NuGet Package Manager

Klik met de rechtermuisknop op het projectknooppunt in Visual Studio en selecteer NuGet-pakketten beheren. Zoek naar Azure.Identity in het zoekveld en installeer het overeenkomende pakket. Herhaal dit proces ook voor het Microsoft.Extensions.Azure-pakket .

Azure-services worden over het algemeen geopend met behulp van bijbehorende clientklassen van de SDK. Deze klassen en uw eigen aangepaste services moeten worden geregistreerd in het Program.cs bestand, zodat ze kunnen worden geopend via afhankelijkheidsinjectie in uw app. Program.csVolg de onderstaande stappen om uw service en DefaultAzureCredential.

1. Neem de Azure.Identity en Microsoft.Extensions.Azure naamruimten op met een using-instructie.
2. Registreer de Azure-service met behulp van relevante helpermethoden.
3. Geef een exemplaar van het DefaultAzureCredential object door aan de UseCredential methode.

Een voorbeeld hiervan wordt weergegeven in het volgende codesegment.

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

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

U kunt ook rechtstreeks in uw services gebruikmaken DefaultAzureCredential zonder de hulp van aanvullende Azure-registratiemethoden, zoals hieronder wordt weergegeven.

using Azure.Identity;

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

Wanneer de bovenstaande code wordt uitgevoerd op uw lokale werkstation tijdens de lokale ontwikkeling, wordt er gezocht in de omgevingsvariabelen voor een toepassingsservice-principal of in Visual Studio, VS Code, de Azure CLI of Azure PowerShell voor een set ontwikkelaarsreferenties, die beide kunnen worden gebruikt om de app tijdens lokale ontwikkeling te verifiëren bij Azure-resources.

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

De volgorde van DefaultAzureCredential-verificatiemethoden verkennen

DefaultAzureCredential Implementeert intern een keten van referentieproviders voor het verifiëren van toepassingen bij Azure-resources. Elke referentieprovider kan detecteren of referenties van dat type zijn geconfigureerd voor de app. DefaultAzureCredential Controleert elke provider op volgorde en gebruikt de referenties van de eerste provider waarvoor referenties zijn geconfigureerd.

De volgorde en locaties waarin DefaultAzureCredential wordt gezocht naar referenties, vindt u op DefaultAzureCredential.

Referentietype	Beschrijving
Toepassingsservice-principal	DefaultAzureCredential leest een set omgevingsvariabelen om te bepalen of een toepassingsservice-principal (toepassingsgebruiker) is ingesteld voor de app. Als dat het zo is, DefaultAzureCredential gebruikt u deze waarden om de app te verifiëren bij Azure. Deze methode wordt meestal gebruikt in serveromgevingen, maar kan ook worden gebruikt bij het lokaal ontwikkelen.
Beheerde identiteit	Als de toepassing wordt geïmplementeerd op een Azure-host waarvoor Managed Identity is ingeschakeld, DefaultAzureCredential wordt de app geverifieerd bij Azure met behulp van die beheerde identiteit. Verificatie met behulp van een beheerde identiteit wordt besproken in de sectie Verificatie in serveromgevingen van dit document. Deze methode is alleen beschikbaar wanneer een toepassing wordt gehost in Azure met behulp van een service zoals Azure-app Service, Azure Functions of Azure Virtual Machines.
Visual Studio	Als de ontwikkelaar zich bij Azure heeft geverifieerd door u aan te melden bij Visual Studio, DefaultAzureCredential verifieert u de app bij Azure met hetzelfde account.
Visual Studio Code	Als de ontwikkelaar is geverifieerd bij Azure met behulp van de invoegtoepassing Azure-account van Visual Studio Code, DefaultAzureCredential wordt de app geverifieerd bij Azure met hetzelfde account.
Azure-CLI	Als een ontwikkelaar is geverifieerd bij Azure met behulp van de az login opdracht in de Azure CLI, DefaultAzureCredential verifieert u de app bij Azure met hetzelfde account.
Azure PowerShell	Als een ontwikkelaar is geverifieerd bij Azure met behulp van de Connect-AzAccount cmdlet van Azure PowerShell, DefaultAzureCredential verifieert u de app bij Azure met hetzelfde account.
Interactief	Indien ingeschakeld, DefaultAzureCredential wordt de ontwikkelaar interactief geverifieerd via de standaardbrowser van het huidige systeem. Deze optie is standaard uitgeschakeld.