Azure Integration using Managed Identity

This blog describes managed identities and different types of managed identities. Managed Identities are in essence similar to Service Principals and they are actually Service Principals. The biggest difference between both is that Azure Managed identities manage the initial creation of the service principal and automatic renewal of the service principal without any additional workload required – Which is great and highly recommended to be used.

The managed identity can be used when the source resource and the target resource are in the same azure ad tenant. That is when Logic App or Function App in the Azure Tenant wants to access the information from the target application in the same tenant such as D365 CE, D365FO, KeyVult

Service Principal

A service principal is An application whose tokens can be used to authenticate and grant access to specific Azure resources or cloud resources from a user-app, third party applications, service, or automation tool when an organization is using Azure Active Directory. This is the approach usually used in integration designs. Service Principal can be considered as a replacement for the Service Account concept on on-premises Active Directory.

Managed Identity

The Managed identity is similar to Service Principal but they are always linked to an Azure Resource (such as Logic App, Azure Functions), not to an application or 3rd party connector. They are created automatically when Managed Identity is enabled for an Azure Resource. This would indeed automatically create a service Principal, but no one knows the credentials. There are two types of Managed identities

• System assigned
• User Assigned

System assigned

These identities are tied directly to an Azure resource such as Logic App, Azure Functions, and abide by that resources’ lifecycle. For instance, if that resource is deleted then the identity too will be removed.

Let’s walk through the scenario of enabling System assigned managed identity for Logic App. Then using the managed identity accessing the Secrets from Azure Key Vault.
Steps to enable managed identity for Logic App

• Go to the Azure Portal
• Select the Logic App and then Open the Logic App
• Under the Settings Tab on the Left, find Identity and click on it
• Then Select System Identity
• Set Status as On, and save the changes. This would create a Managed Identity for the Logic App

Now let’s go to the Key vault where the Secrets are stored, which the previous Logic App needs to Access

• Select the Azure Key Vault and then Open the Key vault
• Under the Settings Tab on the Left, find Access Policies and click on it
• Then Click on Add Access Policy

Then select the Secret Management for Configure from the template, Secret permission to Get and List. Then click on Select Principal and search for the Managed Identity of the Logic App. Then Click Select and Click Add
Then click Save to add the Logic App managed Identity to KeyVaul.

Now Logic App would be able to access the KeyVault Secrets using the following action

User Assigned 

These identities are created independent of an Azure resource, and as such can be used between different resources. Removing them is a manual process whenever you see fit.

This means that you first have to create it as a stand-alone Azure resource by itself, after which it can be linked to multiple Azure Resources. An example here could be out of integration with Key Vault, where different Azure services belonging to the same application stack (such as Logic App, Azure Functions, Web App), need to read out information from Key Vault. In this case, We could create a Single Managed Identity, and link it to the function, Multiple logic apps all belonging to the same application architecture.
Let’s walk through the scenario of creating the user-managed identity, enabling User assigned managed identity for Logic App. Then using the managed identity accessing the Secrets from Azure Key Vault.
Steps to enable managed identity for Logic App

• Go to the Azure Portal
• Create new Resource, and search for “Managed Identities”
• click Create.
• Specify the Resource Group, Azure Region and Name for this resource.

• Select the Logic App and then Open the Logic App
• Under the Settings Tab on the Left, find Identity and click on it
• Then Select User assigned and Click Add
• The search for the User assigned Managed identity which was created and then select. Then click Add.

Now let’s go to the Key vault where the Secrets are stored, which the previous Logic App needs to Access

• Select the Azure Key Vault and then Open the Key vault
• Under the settings Tab on the Left, find Access Policies and click on it
• Then Click on Add Access Policy

Then select the Secret Management for Configure from the template, Secret permission to Get and List. Then click on Select Principal and search for the User Managed Identity which was created. Then Click Select and Click Add
Then click Save to add the User assigned managed Identity to KeyVault.
Then click Save

Now Logic App would be able to access the KeyVault Secrets using following action

conclusion

The managed Identity creation and automatically roll over the service principal is done by Azure for you. This is done by Azure in the background and requires no human/customer intervention. These credentials are rotated/rolled over every 46 days, this is a default behaviour/policy. Put simply, the difference between a managed identity and a service principal is that a managed identity manages the creation and automatic renewal of a service principal on your behalf.