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 😉
Good Workaround! 
👍 I was struggling with this 1; thank you for lots of trial-n-error
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.
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.
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.
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.