Within logic apps API connections are used to communicate safely with different Azure resources. The preferred method of authentication and authorization is Azure Active Directory. Obviously it’s not a good idea to use your own identity in Azure Active Directory. Instead you can use a simple Logic App setting to enable a managed identity.
After that Azure will automatically create a service principal in Azure Active Directory for you. With this identity you can connect to Azure Key Vault, Azure SQL, Azure Service Bus or Azure Blob Storage. For a complete list, see: docs.microsoft.com. There are two types of managed identities:
- System assigned. Linked to a specific Logic App or Function (same lifecycle).
- User assigned. Can be shared by multiple resources.
The main advantage of using a managed identity is that you don’t need to specify any credentials in your code. Credentials are managed for you just like that. You don’t have to look for ways to store your credentials securely. Remember. Managed Identities provide authentication, not authorization. To access service bus or blob storage as an example, you will have to configure role-based access for each resource group you want to access. The only exception is Azure Key Vault. To Azure Key Vault you will have to add access policies, like “PermissionsToSecrets Get, Set”.
Unfortunately there’s one problem in Azure when you want to use managed identities. The custom connectors for Azure Key Vault, Azure SQL, Azure Service Bus and Azure Blob Storage don’t support managed identities yet (status november 2019). Managed identities can only be used with the HTTP connector. Within the HTTP connector select property Authentication and set it to Managed Identity. Since Azure Key Vault, Azure SQL, Azure Service Bus and Azure Blob Storage can all be accessed via a REST API, using the HTTP connector is a valid workaround. Especially for Azure Key Vault. You can store your client secret in Azure Key Vault, but then again, you would need a client secret to access Azure Key Vault. It’s a classic chicken-and-egg situation.
Another alternative for managed identities is to directly create a service principal in Azure Active Directory. Each service principal will have a clientid and clientsecret. The clientsecret can safely be stored in Azure Key Vault. A service principal is effectively the same as a managed identity, it’s just more work and less secure.
Service principals are primary used for accessing Azure Event Managed Identities can not be used with Azure Event Grid. Again, after creating the service principal, you will still have to configure Azure AD access to role EventGrid EventSubscription Contributor for each resource group with an Azure Event Grid you want to access.