Is using Microsoft Azure Managed Identities the only way of using EF Core?

Question

I am rewriting an old ASP.NET WebForms application, into a server-side Blazor application using .NET 8. And I'm also going to use Entity Framework Core 8. I've been following along in these two Microsoft Learn courses DbContext Lifetime, Configuration, and Initialization and ASP.NET Core Blazor with Entity Framework Core (EF Core). The second link insists that it is best to use Microsoft Azure's Managed Identities when using EF Core in a server-side Blazor application.

But I'm wondering, is that absolutely necessary? What if you're using AWS, rather than Azure? Does that mean server-side Blazor with EF Core cannot run in AWS? Or how about GCP? Does that mean server-side Blazor with EF Core cannot run in GCP? I find that hard to believe.

And in my situation, just getting an Azure Key Vault took me 10 months!!!!!!! I put in the request, where it sat for 10 months doing nothing. It's a LONG PROCESS with absolutely no insight or transparency into what is going on or why it is being delayed. At this rate this simple rewrite of the application will take several years before it will be finished due to the multiple of bureaucratic roadblocks, some of which I'm sure I don't even know yet. Bottom line, I'd like to avoid as many dependencies as possible upon other things which will only result in very lengthy delays.

Answer 1

Hi Falanga, is that absolutely necessary -> No. We recommend using Azure Managed Identity when the blazor application and the database are planning to be host in Azure, as many Azure services are supporting Microsoft Entra authentication, and Managed Identity can provide an automatically managed identity in Microsoft Entra ID for applications to use when connecting to resources that support Microsoft Entra authentication. EF Core just relies on a DbContext to configure database access. So that EF core and Managed identity doesn't have direct relationship. But the connection to database requires credential such as connection string/username/password, using Managed Identity brings benefit for managing these credentials if we host the blazor app and its credentials in Azure. If they are not host in Azure, then Managed Identity doesn't have any relationship with EF core and blazor server application.

Just like we all know, we might require a connection string which might containing username and password for a database to connect to database. But storing credentials in codes or configuration files in local machine is not secure. So that we might try to store the connection in Azure key vault. Azure key vault can help protect secured information, and it requires to integrate Microsoft Entra (known as Azure AD before) authentication. This might be what you had done. And your codes might similar to

const string secretName = "clientsecret";
var kvUri = "https://keyvaultname.vault.azure.net/";
var a = new DefaultAzureCredential();
var client = new SecretClient(new Uri(kvUri), a);
var secret = await client.GetSecretAsync(secretName);
string secretVaule = secret.Value.Value;

And since we are about to integrate Microsoft Entra, we could upgrade the security level. If the connection string doesn't contain username and password, it shall be more secure, right? Here we could use Managed Identity if both the blazor app is host in Azure App Service and we could set Managed Identity to target Azure Key Vault and Azure SQL Databaseault and Azure SQL Database(your database is host in Azure). Assuming we store the connection string in Azure Key Vault, next we can follow this blog to connect to Azure Database vault using Managed Identity. If we want to connect to Azure Key Vault using Managed Identity, we can use

var a = new DefaultAzureCredential(
           new DefaultAzureCredentialOptions { ManagedIdentityClientId = "userManagedIdentityClientId" }//when using user ManagedIdentity
       )

You mentioned "multiple of bureaucratic roadblocks" in your case but I think we still need to consider safety issues carefully. How long we need to work on the migration might not the case we need to consider. Anyway, we'd better to find a cloud service to store our security secrets such as Azure Key Vault or corresponding service in AWS or some other cloud service except there's extra policy stops you choosing this plan. Managed identity is not necessary indeed if you are not planning to host all your services in Azure.

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Best regards,

Tiny

Answer 2

Managed Identities is a feature of hosting your .net app in Azure. It handles credentials for azure services at the azure portal level. you don't need to recycle keys, or passwords. Your app has a unique identity, that can be used to access azure resources all configured outside your app. this gets around having to manage the secret to get to the keyvault for other secrets,

If you are not hosting in azure, they are not relevant. You will use other security techniques. for EF either standard security or use windows/kerberos via the application service account. if using standard, you will need to find a secure way to get the credentials.