Ability to parameterize identity for HTTP actions with user-assigned managed identity authentication enabled

[WenovateAA]

Now as LA supports user-assigned managed identity (UAMI) it's possible to have multiple identities assigned per single LA Standard. This is a standard benefit of using UAMI. When it comes to HTTP actions, where you primarily specify such identities for authentication to Azure and Azure AD, you choose it from drop-down list. This didn't change since LA consumption tier. This forces to specify your UAIM id in workflow code. However, it's possible to put it to parameters (and I think use output of previous actions):

            "HTTP": {
                "inputs": {
                    "authentication": {
                        "audience": "@parameters('Audience')",
                        "identity": "@parameters('Identity')",
                        "type": "ManagedServiceIdentity"
                    },
                    "method": "GET",
                    "uri": "@parameters('URL')"
                },
                "runAfter": {},
                "type": "Http"
            }

Here Identity is a string parameter containing Azure resource id. This works as expected. However, Designer shows error displaying such configuration:

Would be good, if UI also allows to specify custom value for UAMI.

Why it is important? Because we try to separate code from parameters, especially when using CI/CD approach. Single code, separate parameters referring to @appsettings depending on environment. Putting Id for UAMI and other env. specific data inside code breaks such concept.

AB#16655441

[erwinkramer]

In fact, using @appsettings at all (deployed in Azure) for the identity element will not work (not from connections.json and not from parameters.json if you first make it a parameter and then reference an app setting via your parameter), it will throw the following error:

WorkflowAppOAuthTokenFailure. Failed to get oauth token for managed identity in logic app. Response: '{"statusCode":400,"message":"No User Assigned or Delegated Managed Identity found for specified ClientId/ResourceId/PrincipalId.","correlationId":"bedf24b8...."}'

You have to hardcode it in your parameters or connections json, not good.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale.

[erwinkramer]

please re-open

[Kaloszer]

Why was this closed? This is still the case late 2023, I'm getting a similar issue. Given that it works for azuresentinel/azureautomation api connectors. It should also be working for this one.

This should be re-opened

[MrRosendahl]

I hope that the Azure team makes all authentication/connections work the same for All Azure actions... instead of only using parameters for individual properties in the "authentication" object you would have a reference to the connection, like they have implemented it in the "invoke workflow" action.

This way you can have one connections.json locally and replace that file when deploying. Then you can use connectionstrings locally and managed identity in Azure.

"connection": {
    "referenceName": "servicebus"
}

[John-Bosch]

In fact, using @appsettings at all (deployed in Azure) for the identity element will not work (not from connections.json and not from parameters.json if you first make it a parameter and then reference an app setting via your parameter), it will throw the following error:

WorkflowAppOAuthTokenFailure. Failed to get oauth token for managed identity in logic app. Response: '{"statusCode":400,"message":"No User Assigned or Delegated Managed Identity found for specified ClientId/ResourceId/PrincipalId.","correlationId":"bedf24b8...."}'

You have to hardcode it in your parameters or connections json, not good.

I just ran in to exactly this! This effectively means you need a different connections.json file for every environment, which means I now need a separate build artifact for every environment. That sucks big time and adds yet another nail into the coffin for Logic Apps as far as I am concerned!

[erwinkramer]

@John-Bosch , magically, i got something like this working (locally and on azure):

"type": "Http",
"inputs": {
    "uri": "someUri",
    "method": "POST",
    "headers": {  },
    "body": {  },
    "authentication": "@parameters('http_authentication')"
},
"runAfter": {},
"runtimeConfiguration": {
    "contentTransfer": {
        "transferMode": "Chunked"
    }
}

and in parameters.json, you get this:

 "http_authentication": {
    "type": "object",
    "value": {
      "type": "ActiveDirectoryOAuth",
      "tenant": "@appsetting('WORKFLOWS_TENANT_ID')",
      "audience": "https://graph.microsoft.com",
      "clientId": "@appsetting('HTTP_CLIENTID')",
      "secret": "@appsetting('HTTP_CLIENTSECRET')"
    }
  },

I still have 2 parameter files, one for azure and one locally, to differentiate large differences (managed Identity vs app registration / connection key), but thats the only thing that differs and it's manageable.