Introduction

A common challenge for developers is the management of secrets, credentials, certificates, and keys used to secure communication between services

One common practice while designing and architecturing authentication for Apps in the Azure Universe is the use of a App Registration as a controlled way to securely access resources in the the Azure universe and it's been for the last years a common pattern in my designs, perhaps yours also!

And if there would be another way of securing access to the Dataverse web services without the need to manage the complexity of secrets, credentials or certificates ?

What are

Managed Indentities

Managed identities eliminate the need for developers to manage credentials

Managed identities provides automatically a managed identity in Microsoft Entra ID for applications to use when connecting to resources that support Microsoft Entra authentication.

Azure Managed Identities are a feature of Azure Active Directory (Azure AD) that allows Azure services to authenticate to other Azure services securely without storing credentials in code or configuration files. They are essentially service principals managed by Azure, providing an identity for applications to use when connecting to resources that support Azure AD authentication.

Types of Managed Identities:
System-Assigned Managed Identity: This identity is enabled directly on an Azure service instance. Azure automatically manages the lifecycle of this identity, and it's tied to the lifecycle of the service instance. When the resource is deleted, the identity is also deleted.

User-Assigned Managed Identity: Created as a standalone Azure resource, this identity can be assigned to one or more Azure service instances. It exists independently of the resources its assigned to, allowing greater flexibility and reusability.

 

Benefits of Using Managed Identities:

Applications can use managed identities to obtain Microsoft Entra ID tokens without having to manage any credentials and:

• You don't need to manage credentials. Credentials aren’t even accessible to you.
• You can use managed identities to authenticate to any resource that supports Microsoft Entra authentication, including your own applications.
• Managed identities can be used at no extra cost.

How to use them

To show how to use managed identities to authenticate an Azure app managed by Azure Entra ID into other Azure Entra ID managed resource I'll use the scenario of an Azure Function that access Dataverse to create a contact.

The following diagram show us the intended scenario.

1- Create Managed Identity

Let's create a managed identity and for that I got another good news that's we don't need to have Entra ID management permissions to create a new one just collaboration on a Azure Resource.

• In a resource group lets create a new managed identity:
  • 
• Once created get the generated "Client ID" 
  • 

2- Configure Power Apps

• Go to the Power Platform admin center
• Then the "Application Users" and select "New app user"
• Use the "Client ID" from the previous step to find the app, because managed identities aren't displayed yet by default!
  • 
• Then complete with the Business Unit (use a custom one) and the Security Roles (use a custom one).  
  • 

3- Azure Function

Now its time to create our Azure Function that will authenticate in Dataverse using the managed identity!

• For this purpose I've created an Azure HTTP Function in a consumption plan
• Then I've used the following code to authenticate in Dataverse:

•    var tokenCredential = new DefaultAzureCredential();
  
     var ConfigServiceDataverseURI = new Uri("https://yyyyyyy.crm4.dynamics.com");
     
     log.LogInformation("ConfigServiceDataverseURI: " + ConfigServiceDataverseURI);
  
     var serviceClient = new ServiceClient(ConfigServiceDataverseURI, async (string dataverseUri) =>
     {
         dataverseUri = new Uri(dataverseUri).GetComponents(UriComponents.SchemeAndServer, UriFormat.UriEscaped);
         return (await tokenCredential.GetTokenAsync(new TokenRequestContext(new[] { dataverseUri }), default)).Token;
     }, true);
  

• And then the create account record part 

• try
  {
  
      if (!serviceClient.IsReady) throw new Exception("Authentication Failed!");
  
      Random random = new Random();
      int randomNumber = random.Next(100000, 999999 + 1);
  
  
      log.LogInformation("randomNumber " + randomNumber);
  
      var registration = new Entity("contact");
      registration["firstname"] = "model.FirstName - " + randomNumber;
      registration["lastname"] = "model.LastName";
  
      serviceClient.Create(registration);
  
  }
  catch (Exception ex)
  {
  
      log.LogError(ex.Message);
  }

• Now lets configure a User assigned Managed Identity for our Azure Function with the created Managed Identity in the step 1

• And then add to the Environmental variables the "AZURE_CLIENT_ID" with the created Managed Identity client ID in the step 1

• Publish you Azure Function and test it, contacts are created without any secret or certificate!
• 

One point that needs attention is that in my example I'm using the DefaultAzureCredential that allows our code to use the credential use locally, in another words it allows to run and debug the code locally.

Either the way using the DefaultAzureCredential will have our application to search for the credentials using the following pipeline (order):

• EnvironmentCredential, 
• ManagedIdentityCredential, 
• SharedTokenCacheCredential, 
• VisualStudioCredential, 
• VisualStudioCodeCredential, 
• AzureCliCredential, 
• AzurePowerShellCredential, 
• InteractiveBrowserCredential

Using the ManagedIdentityCredential will make our code to directly use the Managed Identity declared in our Azure resource.

Why to Use it

Azure Managed Identities provide a secure and streamlined way to authenticate Azure resources with Dataverse, eliminating the need for manual credential management.

By leveraging Managed Identities, developers can enhance security, simplify configuration, and reduce the overhead associated with traditional authentication methods

Comparison with App Registration Authentication
While both Managed Identities and App Registrations can be used for authenticating with Dataverse, there are significant differences:

Managed Identity: Credentials are automatically managed by Azure, removing the need for manual handling and reducing the risk of credential leaks.

Lifecycle and Scope

App Registration: Exists independently within Azure AD and can be used by applications running anywhere, including outside Azure.
Managed Identity: Tied to an Azure resource (system-assigned) or managed as a resource (user-assigned). Primarily intended for use within Azure.

Security

App Registration: Higher risk due to manual credential management. If credentials are compromised, it can lead to unauthorized access.
Managed Identity: Provides enhanced security by avoiding hard-coded credentials, and the credentials are not accessible to developers or users.

Complexity

App Registration: Involves more steps to set up, including creating the app registration, generating secrets or certificates, and configuring permissions.
Managed Identity: Simpler to configure, with Azure handling the creation and rotation of credentials automatically.

 

In summary

Azure Managed Identities offer a more secure and easy approach for authenticating Azure resources with Dataverse compared to App Registrations.

They are ideal for applications running within Azure that require secure access to other Azure resources without the overhead of managing credentials.

However, App Registrations are still very relevant for scenarios where applications run outside of Azure or require specific access scopes.