Come autenticare le app .NET nei servizi di Azure usando .NET Azure SDK
Quando un'applicazione deve accedere a una risorsa di Azure, ad esempio archiviazione, insieme di credenziali delle chiavi o servizi cognitivi, l'applicazione deve essere autenticata in Azure. Questo vale per tutte le applicazioni, sia distribuite in Azure, distribuite in locale o in fase di sviluppo in una workstation per sviluppatori locale. Questo articolo descrive gli approcci consigliati per autenticare un'app in Azure quando si usa Azure SDK per .NET.
Approccio consigliato per l'autenticazione delle app
È consigliabile che le app usino l'autenticazione basata su token anziché le stringhe di connessione durante l'autenticazione alle risorse di Azure. Azure SDK per .NET offre classi che supportano l'autenticazione basata su token e consentono alle app di eseguire facilmente l'autenticazione alle risorse di Azure, indipendentemente dal fatto che l'app sia in fase di sviluppo locale, distribuita in Azure o distribuita in un server locale.
Il tipo specifico di autenticazione basata su token che un'app deve usare per eseguire l'autenticazione alle risorse di Azure dipende dalla posizione in cui viene eseguita l'app ed è illustrata nel diagramma seguente.
- Quando uno sviluppatore esegue un'app durante lo sviluppo locale: l'app può eseguire l'autenticazione in Azure usando un'entità servizio applicazione per lo sviluppo locale o usando le credenziali di Azure dello sviluppatore. Ognuna di queste opzioni viene descritta in modo più dettagliato nella sezione autenticazione durante lo sviluppo locale.
- Quando un'app è ospitata in Azure- L'app deve eseguire l'autenticazione alle risorse di Azure usando un'identità gestita. Questa opzione è illustrata in modo più dettagliato di seguito nella sezione autenticazione negli ambienti server.
- Quando un'app è ospitata e distribuita in locale: l'app deve eseguire l'autenticazione alle risorse di Azure usando un'entità servizio dell'applicazione. Questa opzione è illustrata in modo più dettagliato di seguito nella sezione autenticazione negli ambienti server.
DefaultAzureCredential
La classe DefaultAzureCredential
fornita da Azure SDK consente alle app di usare metodi di autenticazione diversi a seconda dell'ambiente in cui vengono eseguiti. In questo modo le app possono essere promosse dallo sviluppo locale agli ambienti di test all'ambiente di produzione senza modifiche al codice. Configurare il metodo di autenticazione appropriato per ogni ambiente e DefaultAzureCredential
rileverà e userà automaticamente tale metodo di autenticazione. L'uso di DefaultAzureCredential
deve essere preferito rispetto alla codifica manuale della logica condizionale o dei flag di funzionalità per l'uso di metodi di autenticazione diversi in ambienti diversi.
I dettagli sull'uso della classe DefaultAzureCredential
sono descritti più avanti in questo articolo nella sezione Uso DefaultAzureCredential
in un'applicazione.
Vantaggi dell'autenticazione basata su token
L'autenticazione basata su token è fortemente consigliata rispetto all'uso delle stringhe di connessione durante la compilazione di app per Azure. L'autenticazione basata su token offre i vantaggi seguenti rispetto all'autenticazione con le stringhe di connessione.
- I metodi di autenticazione basati su token descritti di seguito consentono di stabilire le autorizzazioni specifiche necessarie per l'app nella risorsa di Azure. Questo segue il principio dei privilegi minimi. Al contrario, un stringa di connessione concede diritti completi alla risorsa di Azure.
- Mentre chiunque o qualsiasi app con una stringa di connessione può connettersi a una risorsa di Azure, i metodi di autenticazione basati su token hanno come ambito l'accesso alla risorsa solo alle app destinate ad accedere alla risorsa.
- Nel caso di un'identità gestita, non esiste alcun segreto dell'applicazione da archiviare. In questo modo l'app è più sicura perché non esiste una stringa di connessione o un segreto dell'applicazione che può essere compromessa.
- Il pacchetto Azure.Identity in Azure SDK gestisce automaticamente i token in background. Ciò semplifica l'uso dell'autenticazione basata su token come stringa di connessione.
L'uso di stringhe di connessione deve essere limitato alle app di verifica iniziali o ai prototipi di sviluppo che non accedono a dati sensibili o di produzione. In caso contrario, le classi di autenticazione basate su token disponibili in Azure SDK devono essere sempre preferite quando si esegue l'autenticazione alle risorse di Azure.
Autenticazione negli ambienti server
Quando si ospita in un ambiente server, a ogni applicazione deve essere assegnata un'identità dell'applicazione univoca per ambiente in cui viene eseguita l'applicazione. In Azure un'identità dell'app è rappresentata da un'entità servizio, un tipo speciale di entità di sicurezza destinata a identificare ed autenticare le app in Azure. Il tipo di entità servizio da usare per l'app dipende dalla posizione in cui è in esecuzione l'app.
Authentication method | Descrizione |
---|---|
App ospitate in Azure | Le app ospitate in Azure devono usare un'entità servizio identità gestita. Le identità gestite sono progettate per rappresentare l'identità di un'app ospitata in Azure e possono essere usate solo con le app ospitate in Azure. Ad esempio, a un'app Web .NET ospitata nel servizio app Azure verrebbe assegnata un'identità gestita. L'identità gestita assegnata all'app verrà quindi usata per autenticare l'app in altri servizi di Azure. |
App ospitate all'esterno di Azure (ad esempio, app locali) |
Le app ospitate all'esterno di Azure (ad esempio le app locali) che devono connettersi ai servizi di Azure devono usare un'entità servizio dell'applicazione. Un'entità servizio applicazione rappresenta l'identità dell'app in Azure e viene creata tramite il processo di registrazione dell'applicazione. Si consideri, ad esempio, un'app Web .NET ospitata in locale che usa Archiviazione BLOB di Azure. Si creerebbe un'entità servizio applicazione per l'app usando il processo di registrazione dell'app. Il AZURE_CLIENT_ID , AZURE_TENANT_ID e AZURE_CLIENT_SECRET verrebbe archiviato come variabili di ambiente da leggere dall'applicazione in fase di esecuzione e consentire all'app di eseguire l'autenticazione in Azure usando l'entità servizio dell'applicazione. |
Autenticazione durante lo sviluppo locale
Quando un'applicazione viene eseguita nella workstation di uno sviluppatore durante lo sviluppo locale, deve comunque eseguire l'autenticazione a tutti i servizi di Azure usati dall'app. Le due strategie principali per l'autenticazione delle app in Azure durante lo sviluppo locale sono:
Authentication method | Descrizione |
---|---|
creare oggetti entità servizio dell'applicazione dedicati da usare durante lo sviluppo locale | In questo metodo, gli oggetti entità servizio dell'applicazione dedicati vengono configurati usando il processo di registrazione dell'app da usare durante lo sviluppo locale. L'identità dell'entità servizio viene quindi archiviata come variabili di ambiente a cui accedere l'app quando viene eseguita nello sviluppo locale. Questo metodo consente di assegnare le autorizzazioni di risorsa specifiche necessarie dall'app agli oggetti entità servizio usati dagli sviluppatori durante lo sviluppo locale. In questo modo, l'applicazione ha accesso solo alle risorse specifiche necessarie e replica le autorizzazioni che l'app avrà nell'ambiente di produzione. Lo svantaggio di questo approccio è la necessità di creare oggetti entità servizio separati per ogni sviluppatore che funziona su un'applicazione. |
Autenticare l'app in Azure usando le credenziali dello sviluppatore durante lo sviluppo locale | In questo metodo, uno sviluppatore deve accedere ad Azure da Visual Studio, dall'estensione Strumenti di Azure per VS Code, dall'interfaccia della riga di comando di Azure o da Azure PowerShell nella workstation locale. L'applicazione può quindi accedere alle credenziali dello sviluppatore dall'archivio credenziali e usare tali credenziali per accedere alle risorse di Azure dall'app. Questo metodo offre il vantaggio di una configurazione più semplice perché uno sviluppatore deve accedere solo al proprio account Azure da Visual Studio, VS Code o dall'interfaccia della riga di comando di Azure. Lo svantaggio di questo approccio è che l'account dello sviluppatore ha probabilmente più autorizzazioni rispetto a quelle richieste dall'applicazione. Di conseguenza, questo approccio non replica in modo accurato le autorizzazioni con cui verrà eseguita l'app nell'ambiente di produzione. |
Usare DefaultAzureCredential in un'applicazione
DefaultAzureCredential
supporta più metodi di autenticazione e determina il metodo di autenticazione usato in fase di esecuzione. In questo modo, l'app può usare metodi di autenticazione diversi in ambienti diversi senza implementare codice specifico dell'ambiente.
L'ordine e le posizioni in cui DefaultAzureCredential
cerca le credenziali sono disponibili in DefaultAzureCredential.
Per implementare DefaultAzureCredential
, aggiungere prima di tutto il pacchetto Azure.Identity
e facoltativamente i pacchetti Microsoft.Extensions.Azure
all'applicazione. A tale scopo, è possibile usare la riga di comando o Gestione pacchetti NuGet.
Aprire l'ambiente terminale desiderato nella directory del progetto dell'applicazione e immettere il comando seguente.
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
I servizi di Azure sono in genere accessibili usando le classi client corrispondenti dall'SDK. Queste classi e i propri servizi personalizzati devono essere registrati nel file Program.cs
in modo da poter essere accessibili tramite l'inserimento delle dipendenze in tutta l'app. All'interno di Program.cs
, seguire questa procedura per configurare correttamente il servizio e DefaultAzureCredential
.
- Includere gli spazi dei nomi
Azure.Identity
eMicrosoft.Extensions.Azure
con un'istruzione using. - Registrare il servizio di Azure usando i metodi helper pertinenti.
- Passare un'istanza dell'oggetto
DefaultAzureCredential
al metodoUseCredential
.
Un esempio è illustrato nel segmento di codice seguente.
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());
});
In alternativa, è anche possibile usare DefaultAzureCredential
nei servizi più direttamente senza l'aiuto di altri metodi di registrazione di Azure, come illustrato di seguito.
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()));
Quando il codice precedente viene eseguito nella workstation locale durante lo sviluppo locale, cercherà nelle variabili di ambiente un'entità servizio dell'applicazione o in Visual Studio, VS Code, nell'interfaccia della riga di comando di Azure o in Azure PowerShell un set di credenziali per sviluppatori, che possono essere usate per autenticare l'app nelle risorse di Azure durante lo sviluppo locale.
Quando distribuito in Azure, lo stesso codice può anche autenticare l'app in altre risorse di Azure. DefaultAzureCredential
può recuperare automaticamente le impostazioni dell'ambiente e le configurazioni dell'identità gestita per l'autenticazione ad altri servizi.
Esplorazione della sequenza dei metodi di autenticazione DefaultAzureCredential
Internamente, DefaultAzureCredential
implementa una catena di provider di credenziali per l'autenticazione delle applicazioni nelle risorse di Azure. Ogni provider di credenziali è in grado di rilevare se le credenziali di quel tipo sono configurate per l'app. DefaultAzureCredential
controlla in sequenza ogni provider in ordine e usa le credenziali del primo provider con credenziali configurate.
L'ordine e le posizioni in cui DefaultAzureCredential
cerca le credenziali sono disponibili in DefaultAzureCredential.
Tipo di credenziali | Descrizione |
---|---|
Entità servizio applicazione | DefaultAzureCredential legge un set di variabili di ambiente per determinare se è stata impostata un'entità servizio applicazione (utente applicazione) per l'app. In questo caso, DefaultAzureCredential usa questi valori per autenticare l'app in Azure.Questo metodo viene usato più spesso negli ambienti server, ma può essere usato anche durante lo sviluppo in locale. |
Identità gestita | Se l'applicazione viene distribuita in un host di Azure con identità gestita abilitata, DefaultAzureCredential autentica l'app in Azure usando tale identità gestita. L'autenticazione con un'identità gestita è descritta nella sezione Autenticazione negli ambienti server di questo documento.Questo metodo è disponibile solo quando un'applicazione è ospitata in Azure usando un servizio come Servizio app di Azure, Funzioni di Azure o Macchine virtuali di Azure. |
Visual Studio | Se lo sviluppatore ha eseguito l'autenticazione in Azure accedendo a Visual Studio, DefaultAzureCredential autentica l'app in Azure usando lo stesso account. |
Visual Studio Code | Se lo sviluppatore ha eseguito l'autenticazione in Azure usando il plug-in dell'account Azure di Visual Studio Code, DefaultAzureCredential autentica l'app in Azure usando lo stesso account. |
Interfaccia della riga di comando di Azure | Se uno sviluppatore ha eseguito l'autenticazione in Azure usando il comando az login nell'interfaccia della riga di comando di Azure, DefaultAzureCredential autentica l'app in Azure usando lo stesso account. |
Azure PowerShell | Se uno sviluppatore ha eseguito l'autenticazione in Azure usando il cmdlet Connect-AzAccount da Azure PowerShell, DefaultAzureCredential autentica l'app in Azure usando lo stesso account. |
Interattivo | Se abilitata, DefaultAzureCredential autentica lo sviluppatore in modo interattivo tramite il browser predefinito del sistema corrente. L'opzione è disabilitata per impostazione predefinita. |