Nello script #171 abbiamo visto come far accedere una Azure App ad un database SQL senza l'ausilio di credenziali. Grazie al System Assigned Identity possiamo trattare l'app come se fosse un'utenza alla quale dare uno specifico accesso al nostro database. Questo approccio è molto comodo ma ha dei limiti. In presenza di più App Service o Virtual Machine, ad esse è necessario dare uno specifico permesso per accedere alle risorse Azure, tra le quali SQL Database.
In alternativa al System Assigned Identity possiamo quindi utilizzare lo User Assigned Identity. In questo caso, invece di avere un'identità per ogni risorsa, l'identità è da noi creata e poi assegnata ai servizi di computazione, in modo che questi si autentichino e accedano alle risorse, tutte allo stesso modo.
Per prima cosa è necessario quindi creare l'identità, accedendo alla sezione apposita Managed Identity, disponibile sempre dal portale.
Gli assegniamo semplicemente un nome e ci annotiamo il Client ID, utile in un successivo momento. A questo punto ci rechiamo sul nostro App Service (la procedura è identica anche per una Virtual Machine) e sempre nella sezione Identity troviamo la voce User Assigned. Qui possiamo aggiungere uno o più identità da assegnare all'app.
La facoltà di assegnare più identità ci permette di impersonificare un'utenza all'interno del nostro applicativo a seconda delle necessità. Per questo motivo, riprendendo il codice visto nello script 171, è necessario che alla classe AzureServiceTokenProvider passiamo una stringa di connessione nella quale specifichiamo il Client ID che ci siamo segnati in precedenza.
var azureServiceTokenProvider = new AzureServiceTokenProvider("RunAs=App;AppId=db7e259d-8008-4172-a178-d87f4bdca974"); string token = await azureServiceTokenProvider.GetAccessTokenAsync("https://database.windows.net/");
Nello script precedente per semplicità è inserito direttamente nel codice, ma l'ideale è recuperarlo dalle configurazioni. Se omesso, magari, consigliamo di non passare alcuna stringa di connessione per supportare lo sviluppo in locale tramite Visual Studio, visto nello script #170. Fatto questo dobbiamo assegnare i permessi di accesso SQL come già fatto nello script #171, usando come nome l'identità creata.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Utilizzare i primary constructor in C#
Generare token per autenicarsi sulle API di GitHub
Eseguire operazioni sui blob con Azure Storage Actions
Reactive form tipizzati con FormBuilder in Angular
Testare l'invio dei messaggi con Event Hubs Data Explorer
Migliorare la scalabilità delle Azure Function con il Flex Consumption
Ordine e importanza per @layer in CSS
Utilizzare Copilot con Azure Cosmos DB
Usare le navigation property in QuickGrid di Blazor
Supportare lo HierarchyID di Sql Server in Entity Framework 8
Migrate and Modernize your .NET Applications on Azure
Sviluppare un'interfaccia utente in React con Tailwind CSS e Preline UI
I più letti di oggi
- Sfruttare le API di geolocalizzazione di JavaScript
- Webcast 'Windows Vista: WinFX il framework per gli sviluppatori'
- Impostare il tema light o dark utilizzando i CSS
- Proteggere le risorse Azure con private link e private endpoints
- Cambiare automaticamente lo stato di un work item in una pipeline di Azure DevOps
- Criptare la comunicazione con mTLS in Azure Container Apps
- Ottimizzare l'aggiornamento di una entity sul database con Entity Framework
- Usare entità non mappate come parametri in metodi Invoke di WCF Ria Services e Silverlight
- Annunciata la licenza commerciale di Kinect for Windows: dal primo febbraio 2012