Azure integration: Securing Logic app HTTP trigger endpoints

Why Secure Logic App with HTTP Trigger?

The LogicApps with the HTTP Request Trigger is a publicly exposed endpoint, which can be accessed over the internet. These endpoints need to be secured, otherwise, anyone with the URL can post the information to the Logic APP and trigger the Logic App.

By default, The endpoint is secured via a couple of mechanisms, including HTTPS and a SAS token. This URL consists of the endpoint address of the Logic App and workflow trigger, and with the following query parameters:

Query parameter	Description
api-version	2016-10-01. Specifies the version of the API
sp	Specifies permissions for the allowed HTTP methods to use.
sv	Specifies the SAS version to use for generating the signature.
sig	Specifies the signature (shared access signature) to use for authenticating access to the trigger. This signature is generated by using the SHA256 algorithm with a secret access key on all the URL paths and properties. Never exposed or published, this key is kept encrypted and stored with the logic app. Your logic app authorizes only those triggers that contain a valid signature created with the secret key.

For Most organizations, there should be an additional form of security to meet their security needs. The following is the list of security options to secure the Logic App endpoints.

• Access the endpoint using SharedAccess Token: Default
• Restrict based IP
• Authorization using Logic App
• Logic Apps and APIM (Azure API Management)
• Expose Logic App as API
• Deploying Logic App in an isolated environment.

Access the endpoint using SharedAccess Token: Default

The SAS signature in the endpoint gives the option to renew the access key periodically or when the endpoints are compromised, but having the SAS token associated with our Logic App is for Authentication, and Authorization in the URL can be problematic. Anyone who knows these token details can easily be sent across inappropriate requests. It is always wise to hide those details or pass them as a header property. The approach to renew the SAS token has shown in the below diagram. The steps to renew are: Go to the Logic App > Find Settings Tab on the Left > Click on Access Keys > Click on “Regenerate Access Key” > Click Ok

Warning! Regenerating the access key will invalidate all SAS URLs created using the select access key and will require calling applications to acquire the new SAS URLs.

For the Most of the organizations, these form of security will not meet the security needs as the URL, that includes SAS token, can be copied and used outside the organization without much governance.

Access control using IP based restriction

The Logic App provides out-of-the-box IP-based security. It is possible to restrict or allow a specific IP address or range of IP addresses. The steps to configure are: Go to the Logic App > Find Settings Tab on the Left > Click on Workflow settings > Select Specific IP ranges > Add Allowed IP ranges or IP Address
The Access control configuration of Logic App provides the option to restrict inbound IP addresses and this will ensure that only trusted IP addresses can call a logic app.
Allowed inbound IP address settings provide the option to restrict calls to triggers in this logic app to the provided IP ranges. IP addresses can be either IPv4 or IPv6 and accept range and bitmask range formats. The access control configuration also provides an option to Restrict calls to get input and output messages from run history to the provided IP ranges. More info on this can be found here

Authorization using Logic App

The Logic App has a feature called “Authorization“, which can be used to authorize Logic App HTTP endpoints using OAuth token. The inbound calls to a Logic App HTTP endpoints can have Azure AD OAuth by defining or adding an authorization policy for the logic app. This way, inbound calls use OAuth access tokens for authorization. When the Logic App HTTP endpoints receive an inbound request that includes an OAuth access token, the Azure Logic Apps service compares the token’s claims against the claims specified by each authorization policy. If a match exists between the token’s claims and all the claims in at least one policy, authorization succeeds for the inbound request. The token can have more claims than the number specified by the authorization policy.

Considerations before you enable Azure AD OAuth

• An inbound call to the request endpoint can use only one authorization scheme, either Azure AD OAuth or Shared Access Signature (SAS). Although using one scheme doesn’t disable the other scheme, using both schemes at the same time causes an error because the Logic Apps service doesn’t know which scheme to choose.
• Only Bearer-type authorization schemes are supported for Azure AD OAuth access tokens, which means that the Authorization header for the access token must specify the Bearer type.
• Your logic app is limited to a maximum number of authorization policies. Each authorization policy also has a maximum number of claims. For more information, see the Limits and configuration for Azure Logic Apps.
• An authorization policy must include at least the Issuer claim, which has a value that starts with either https://sts.windows.net/ or https://login.microsoftonline.com/ (OAuth V2) as the Azure AD issuer ID.

Enable Authorization for Logic App

1. In the Azure portal, find and open your logic app in the Logic App Designer.
2. On the logic app menu, under Settings > select Authorization > After the Authorization pane opens, select Add policy.
3. Then Click on “Add policy“
4. Provide information about the authorization policy by specifying the claim types and values that your logic app expects in the access token presented by each inbound call to the Request trigger:The following field values need to be filled in
   Policy name: The name that you want to use for the authorization policy
   Claims: The claim types and values that your logic app accepts from inbound calls. The claim value is limited to a maximum number of characters. Here are the available claim types:
   – Issuer: It should have a value that starts with https://sts.windows.net/ or https://login.microsoftonline.com/ as the Azure AD issuer ID.
   – Audience
   – Subject
   – JWT ID (JSON Web Token identifier)
5. To add a custom claim, select Add custom claim. For more information, see how to provide optional claims to your app. e.g. Application ID (client id), to ensure that only tokens from only this client id are accepted. This e.g. can be seen in diagram (step 8)
6. To add another authorization policy, select Add policy.
7. When you’re done, select Save.

Trigger LogicApp HTTP endpoint with OAuth token

In the Azure portal, find and open your logic app in the Logic App Designer. Then open the HTTP trigger action and copy the URL

The URL would look like: https://prod-92.westeurope.logic.azure.com:443/workflows/67c65bd243ff465fb67cce62b9cfd418/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=_EFaEW4ye9h215tEvRXcqse5_BU45jdWAxagZQ3E9M0
The removal of the signature from the URL as the inbound call to the request endpoint can use only one authorization scheme, either Azure AD OAuth or SAS.
The modified URL will be : https://prod-92.westeurope.logic.azure.com:443/workflows/67c65bd243ff465fb67cce62b9cfd418/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun

Now we can call the Logic App endpoint (mentioned above) with the OAuth token (Bearer key ) in the header. As shown below

If the access tokens are valid, then the Logic App will proceed with the execution. The following errors will be thrown when the access token (bearer) is invalid.

Expired Token: The provided token is expired and valid till: ‘5/09/2020 11:57:04 AM’ UTC. Please try again with the refreshed token.”
Invalid Claim/Claim Mismatch: One or more claims either missing or does not match with the open authentication access control policy.
The with SAS Token: The request has both SAS authentication scheme and ‘Bearer’ authorization scheme. Only one scheme should be used.

• Export Data from D365 FO using Synapse Link
• D365 FO introduces New user-based service protection API limits
• D365 FO: Priority based throttling for integrations
• Monitoring and alerting for Azure Key Vault
• D365 FO: Set financial dimension value using oData
• Azure Integration using Managed Identity

Azure integration: Securing Logic app HTTP trigger endpoints

Tweet