Using managed identities with logic apps

How I used managed identities with Logic Apps at Arctic Cloud Developer Challenge 2020

This is one of several posts I have planned as the aftermath of Arctic Cloud Developer Challenge 2020. I am going to explain the technologies I used to build my Voting Machine and corresponding Vote Manipulation System. In this post I'll explain how I used managed identities and how I leveraged them to improve security.

What are managed identities?


Managed identity (formerly Managed Service Identity) is an Azure AD object which is tightly coupled to a service principal, it shows as only one object and deleting one means deleting both, and connected to another Azure Resource (like a VM or an App Service). We have two types, one is System Assigned Managed Identity (SMI), where Azure automatically creates one and connects it to your resource, and then we have User Assigned Managed Identity (UMI) which is an Azure resource itself connected to a System Assigned Managed Identity. The user assigned can be used for several services. The system assigned MI automatically gets deleted when the resource is deleted, while the user managed one needs to be deleted manually.

When do I use what?

It depends, but as a general rule I'll give you this: If two or more resources need the same access to the same services, use User Assigned Managed Identity, otherwise use System Assigned. For example if you're using both Function Apps and Logic Apps that access the same services, you can use the user assigned for both of them. They are just like traditional service accounts, and you should provide your services with as little access as possible.

Why use them?

Using managed identities is a great way to prevent having to deal with credentials. Instead of providing a service with a variant of a username and password or a security certificate used to authenticate you have created a link between a resource and a service principal, and the resource can then retrieve a valid auth token directly from Azure AD. That means no credentials in a config file, no certificates in a certificate store, and no client secrets stored in a key vault. The only way to get those credentials would be to figure out a way to hack an AAD service principal (good luck!).

Using managed identities with an Azure Logic App


Azure Logic Apps are awesome. It's a mostly click-and-point tool to get a lot of work done in a short time, and they are relatively easy to debug. It's not for complex logic, efficient processing or moving large amounts of data, but it works great for most interfacing tasks. The reason why I chose Logic Apps to perform a lot of the logic was that unlike Flow it supports managed identities. Where flow needs to store connector credentials and mask secret information from input/output debugging, Logic Apps simply retrieves an access token on demand with a short validity period and uses that to perform the tasks at hand. No going into an Azure Key Vault or creating a custom connector with inbuilt security. Additionally, running a Logic App as a service principal means not having to deal with which user is going to own and run the flow.

To use a managed identity simply go into the settings for a logic app (so you need to create the resource first), then go to the identity section. Switch the status to on and hit save. Azure will create a new SMI and connect it to your app.

Using the managed identity

What I needed to do in this logic app was capture responses from an Office Forms form and post it to a custom API I had built (check out my next post on how to enable MSI to authenticate against an Azure Function). I first created a trigger for when a response came in, and then another step to retrieve the actual response (why isn't there a trigger which could retrieve the data as well? SMH).
Next I added an Azure Function action to my logic app, and then I get to click and select which function I want to call, and which action I want



Next I add the content body, then add a parameter for authentication. Here I select managed identity as authentication type, and select the SMI as the managed identity I want to use. Finally I have to specify the audience, which is configured on the App Registration for the azure function


Testing the app

Finally I'm ready to test the app. So what I do is add a new response to the form and submit. I check out the logic app run history and I can see that it's all green. If you go into the details and check the raw input and raw output you'll see that you can't actually see any authentication details, but you can see that authentication type is set to ManagedServiceIdentity.



So you get to see what actually happens during input and output, but the authentication bit is completely opaque and there's no risk of users extracting data from the run history.

Wrap-up

Using managed identities with Azure Logic Apps is a breeze, and the added security benefit is infinitely better than having to specify credentials in a connector. When you've built everything from scratch like I did for this hackathon then you don't need to store secrets in a Key Vault either, but if you did you could still give access to the managed identity for that logic app.
Check out my next post to see how to allow MSI authentication in an Azure Function.

Until next time!
First