Accessing an Azure AD Protected API Management Instance From Logic Apps Using Managed Identity

I recently embarked on a journey with my colleagues Marius Rochon and Lukman Balunywa to uncover all the details involved in accessing an Azure AD protected APIM instance from Logic Apps using Managed Identity.

The recommended solution is to enable managed identity on the Logic Apps which would allow us to authenticate to Azure AD protected APIs directly with the application’s managed identity. This would allow us to skip creating the application registration, client secret/certificate, and Azure Key Vault entirely as shown in Figure 1.

Figure 1: Generating an access token using Managed Identity

Whereas the solution demonstrated in Figure 1 is desirable and recommended, we couldn’t utilize it in our scenario as the Logic App token request is directed at an authority (AAD) different than the one that controls the Logic App’s Managed Identity and at the time of writing this post Managed Identities did not support cross-directory scenarios. Thus, the most secure solution in this scenario was to configure our Logic App to use its Managed Identity to get access to a Key Vault which holds a certificate that is used to sign an OAuth2 token request. Figure 2 shows the suggested solution.

Figure 2: Logic App uses its Managed Identity to get access to a Key Vault which holds a certificate that is used to sign an OAuth2 token request

The rest of this post uncovers the details involved in achieving the architecture demonstrated in Figure 2.

SYSTEM ASSIGNED VS. USER ASSIGNED MANAGED IDENTITIES

Before we dive into the solution its important to understand the different types of Managed Identities. There are two types of Managed Identities:

• System-assigned: Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity an identity is created in Azure AD that is tied to the lifecycle of that service instance. So when the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD. This is the preferred approach if your apps need different roles for different services.