ARM – Getting the service principal objectid for a Logic App using managed identity

This will be my shortest blog post ever. Here is a way to get the service principal of the managed identity for a Logic App, deployed using ARM. This is everything you need to i.e. add an access policy to keyvault:

    "outputs": {
        "principalId": {
            "type": "string",
            "value": "[reference(concat(resourceId('Microsoft.Logic/workflows', parameters('name')), '/providers/Microsoft.ManagedIdentity/Identities/default'), '2018-11-30').principalId]"
        "tenantId": {
            "type": "string",
            "value": "[reference(concat(resourceId('Microsoft.Logic/workflows', parameters('name')), '/providers/Microsoft.ManagedIdentity/Identities/default'), '2018-11-30').tenantId]"

The ‘name’ variable is the name of the LogicApp, logically enough 😉

5 thoughts on “ARM – Getting the service principal objectid for a Logic App using managed identity

  1. So this is a way to output that value to see it — but how to then use it in the logic app workflow? If all we want to do is look at the value, it shows up in Azure Portal under the “identity” blade for the logic app. And if we want to use it in another ARM, we can use the reference function.

    1. This ARM template can be used as a module under other ARM templates, or using Terraform. Yes you can look at it in the Azure Portal, but that’s not really infrastructure as code. And yes, you can simply use the reference function in the other ARM template, but the reference function is not available in Terraform 🙂

      If I understand you correctly, you want to get the service principal id (objectid) of the assigned managed service identity inside of the logic app workflow itself? That’s a whole different issue, which I also had a need for a while back, and actually did not find a good solution foras far as I recall.

  2. Have you attempted to use this to set a role in an ARM template that also creates the logic app. I’m struggling with this. Even though I have a DependsOn in the roleAssignment resource, the ARM template fails with error Microsoft.Logic/Workflows/ was not found. I’ve traced it down to the attempt to reference the Logic App service principal using this method. If I run the same template a second time, it completes successfully.

    Also, looking at the deployment in the portal, I can see that the identity call always happens first — entirely ignoring my dependsOn clause.

    1. Hi James, unfortunately yes, I have even opened a support ticket with Microsoft on this, and that was closed with “By design”. The recommendation is to use user assigned identities rather than system assigned.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s