How to refer to a Logic App standard connection from HTTP authentication input

Question

Problem: Currently our team is working on a solution to switch between multiple connection.json files which defers between Azure Cloud and Local Development. Since Managed Identities does not work locally while debugging and developing Workflows, we have multiple connection.json files. To change between Managed Identity and Connection String we can easily switch between serviceProviderConnections using for example ServiceBus and Blob. We also want to apply this strategy for other authentication requirements for other actions such as Authentication Input on HTTP actions. Somehow I don't get this to work.

What we have tried: We tried to create a managedApiConnection using the connections.json, but somehow this does not work. (for service bus and blob we use: serviceProviderConnections) In the workflow itself we want to switch between Managed Identity HTTP Action Input and ActiveDirectoryOAuth HTTP Action Input like this: For local development

"authentication": {
    "type": "ActiveDirectoryOAuth",
    "tenant": "common",
    "audience": "@{parameters('graph-audience')}",
    "clientId": "@appsetting('WORKFLOWAPP_AAD_CLIENTID')",
    "credentialType": "Secret",
    "secret": "@appsetting('WORKFLOWAPP_AAD_CLIENTSECRET')"
}

For Azure Cloud Env:

"authentication": {
    "type": "ManagedServiceIdentity",
    "identity": "@{parameters('logicApp_identity')}",
    "audience": "@{parameters('graph-audience')}"
}

We tried to add this as a connection type in the managedApiConnections section without success like this:

"http": {
  "displayName": "Connection",
  "serviceProvider": {
    "id": "/serviceProviders/NAME"
  },
  "parameterSetName": "ActiveDirectoryOAuth",
  "authentication": {
    "type": "ActiveDirectoryOAuth",
    "audience": "@{parameters('audience')}",
    "credentialType": "Secret",
    "clientId": "@appsetting('WORKFLOWAPP_AAD_CLIENTID')",
    "tenant": "@appsetting('WORKFLOWAPP_AAD_TENANTID')",
    "secret": "@appsetting('WORKFLOWAPP_AAD_CLIENTSECRET')"
  }
}

To put things in a greater perspective, this is what such an HTTP Action looks like:

"HTTP_-_GET_NAME": {
    "type": "Http",
    "inputs": {
        "uri": "@{parameters('url')}",
        "method": "GET",
        "headers": {
            "HeaderName": "@{parameters('HeaderValue')}"
        },
        "authentication": {
            "type": "ActiveDirectoryOAuth",
            "tenant": "common",
            "audience": "@{parameters('audience')}",
            "clientId": "@appsetting('WORKFLOWAPP_AAD_CLIENTID')",
            "credentialType": "Secret",
            "secret": "@appsetting('WORKFLOWAPP_AAD_CLIENTSECRET')"
        },
        // "authentication": {
        //     "type": "ManagedServiceIdentity",
        //     "identity": "@{parameters('identity')}",
        //     "audience": "@{parameters('audience')}"
        // }
    },
    "runtimeConfiguration": {
        "contentTransfer": {
            "transferMode": "Chunked"
        }
    }
}

Summary goal: Our goal is to keep the workflows as they are and move the authentication input to the connection file. How can we implement this for such an HTTP Input Authentication method. In the example above the commented auth type is the primary one which we use in the Azure Cloud. This solution is based on the following interesting blog posts: Logic App Standard Connections Solution and Logic App Standard Script Deploy

Answer 1

I've been having the same problem and I found a workable solution.

Rather than using a managedApiConnection in the connections.json file, in your parameters.json file add this (as per your example):

"webApiAuthentication": {
  "type": "object",
  "value": {
    "type": "ActiveDirectoryOAuth",
    "tenant": "common",
    "audience": "@appsetting('graph-audience')",
    "clientId": "@appsetting('WORKFLOWAPP_AAD_CLIENTID')",
    "credentialType": "Secret",
    "secret": "@appsetting('WORKFLOWAPP_AAD_CLIENTSECRET')"
  }
}

This will be used during local development. For deployment to Azure, create a new file called parameters.azureenv.json and put this in it:

"webApiAuthentication": {
  "type": "object",
  "value": {
    "type": "ManagedServiceIdentity",
    "identity": "@appsetting('logicApp_identity')",
    "audience": "@appsetting('graph-audience')"
  }
}

Note that I've put all the settings into the appsettings; for local development these will be in the local.settings.json file, while the appsettings deployed to the Logic App Standard resource in Azure will be set using your ARM template (or Bicep / Terraform), and will be appropriate to the environment (dev/stage/prod, etc.).

In your Logic App workflow, the HTTP action needs to look like this:

"HTTP_-_GET_NAME": {
  "type": "Http",
  "inputs": {
    "uri": "@{parameters('url')}",
    "method": "GET",
    "headers": {
      "HeaderName": "@{parameters('HeaderValue')}"
    },
    "authentication": "@parameters('webApiAuthentication')"
  },
  "runtimeConfiguration": {
    "contentTransfer": {
      "transferMode": "Chunked"
    }
  }
}

Because the parameter webApiAuthentication is defined as an object, when using the local or deployed version the whole thing is substituted in, and it doesn't matter that they have different shapes.

In addition to the above, the mechanism for deploying this into Azure has to be considered, because the parameters.azureenv.json has to become parameters.json when deployed. Firstly, make sure that all the parameters files end up in the ZIP file used to deploy the Logic App Standard resource. Then, follow these steps in your Azure DevOps pipeline (or whatever other deployment tool you use):

• Extract the zip file to a temporary location;

• In the temporary location, delete the parameters.json file (which currently contains the settings only applicable to local running of the Logic App project). Also rename the parameters.azureenv.json file to parameters.json. I used a PowerShell script for all this;

• Zip up the modified contents of the temporary location into a new zip file.

• Deploy the newly created zip file to the Logic App Standard resource.

Once all this is done, you should be able to run the Logic App locally, and the deployed version will also work, and the Logic App remains the same. I've seen some other solutions online that require changes to the code in the Logic App during deployment, but my solution avoids that complication.