|
| 1 | +--- |
| 2 | +title: Securely integrate Azure Logic Apps with on-premises APIs using Azure Active Directory Application Proxy |
| 3 | +description: Azure Active Directory's Application Proxy lets cloud-native logic apps securely access on-premises APIs to bridge your workload. |
| 4 | +services: active-directory |
| 5 | +author: kfriede |
| 6 | +manager: |
| 7 | +ms.service: active-directory |
| 8 | +ms.subservice: app-proxy |
| 9 | +ms.workload: identity |
| 10 | +ms.topic: how-to |
| 11 | +ms.date: 01/19/2023 |
| 12 | +ms.author: kfriedemann |
| 13 | +ms.reviewer: |
| 14 | +ms.custom: |
| 15 | +--- |
| 16 | +# Securely integrate Azure Logic Apps with on-premises APIs using Azure Active Directory Application Proxy |
| 17 | + |
| 18 | +Azure Logic Apps is a service allowing easy creation of managed workflows in a no-code environment that can integrate with various external services and systems. This can help automate a wide range of business processes, such as data integration, data processing, and event-driven scenarios. |
| 19 | +While Logic Apps easily integrate with other public and cloud-based services, the need may arise to utilize Logic Apps with protected, on-premises applications and services without exposing the service to the public via port forwarding or a traditional reverse proxy. |
| 20 | + |
| 21 | +This article describes the steps necessary to utilize the Azure AD Application Proxy solution to provide secure access to a Logic App, while protecting the internal application from unwanted actors. The process and end result is similar to [Access on-premises APIs with Azure Active Directory Application Proxy](./application-proxy-secure-api-access.md) with special attention paid to utilizing the API from within a Logic App. |
| 22 | + |
| 23 | +## Overview |
| 24 | + |
| 25 | +The following diagram shows a traditional way to publish on-premises APIs for access from Azure Logic Apps. This approach requires opening incoming TCP ports 80 and/or 443 to the API service. |
| 26 | + |
| 27 | + |
| 28 | + |
| 29 | +The following diagram shows how you can use Azure AD Application Proxy to securely publish APIs for use with Logic Apps (or other Azure Cloud services) without opening any incoming ports: |
| 30 | + |
| 31 | + |
| 32 | + |
| 33 | +The Azure AD App Proxy and associated connector facilitate secure authorization and integration to your on-premises services without additional configuration to your network security infrastructure. |
| 34 | + |
| 35 | +## Prerequisites |
| 36 | + |
| 37 | +To follow this tutorial, you will need: |
| 38 | + |
| 39 | +- Admin access to an Azure directory, with an account that can create and register apps |
| 40 | +- The *Logic App Contributor* role (or higher) in an active tenant |
| 41 | +- Azure Application Proxy connector deployed and an application configured as detailed in [Add an on-premises app - Application Proxy in Azure Active Directory](./application-proxy-add-on-premises-application.md) |
| 42 | + |
| 43 | +> [!NOTE] |
| 44 | +> While granting a user entitlement and testing the sign on is recommended, it is not required for this guide. |
| 45 | +
|
| 46 | +## Configure the Application Access |
| 47 | + |
| 48 | +When a new Enterprise Application is created, a matching App Registration is also created. The App Registration allows configuration of secure programmatic access using certificates, secrets, or federated credentials. For integration with a Logic App, we will need to configure a client secret key, and configure the API permissions. |
| 49 | + |
| 50 | +1. From the Azure portal, open **Azure Active Directory** |
| 51 | + |
| 52 | +2. Select the **App Registrations** menu item from the navigation pane |
| 53 | + |
| 54 | +  |
| 55 | + |
| 56 | +3. From the *App Registrations* window, select the **All applications** tab option |
| 57 | + |
| 58 | +4. Navigate to the application with a matching name to your deployed App Proxy application. For example, if you deployed *Sample App 1* as an Enterprise Application, click the **Sample App 1** registration item |
| 59 | + |
| 60 | + > [!NOTE] |
| 61 | + > If an associated application cannot be found, it may have not been automatically created or may have been deleted. A registration can be created using the **New Registration** button. |
| 62 | +
|
| 63 | +5. From the *Sample App 1* detail page, take note of the *Application (client) ID* and *Directory (tenant) ID* fields. These will be used later. |
| 64 | + |
| 65 | +  |
| 66 | + |
| 67 | +6. Select the **API permissions** menu item from the navigation pane |
| 68 | + |
| 69 | +  |
| 70 | + |
| 71 | +7. From the *API permissions* page: |
| 72 | + |
| 73 | + 1. Click the **Add a permission** button |
| 74 | + |
| 75 | + 2. In the *Request API permissions* pop-up: |
| 76 | + |
| 77 | + 1. Select the **APIs my organization uses** tab |
| 78 | + |
| 79 | + 2. Search for your app by name (e.g. *Sample App 1*) and select the item |
| 80 | + |
| 81 | + 3. Ensure *Delegated Permissions* is **selected**, then **check** the box for *user_impersonation* |
| 82 | + |
| 83 | + 4. Click **Add permissions** |
| 84 | + |
| 85 | + 3. Verify the configured permission appears |
| 86 | + |
| 87 | +  |
| 88 | + |
| 89 | +8. Select the **Certificates & secrets** menu item from the navigation pane |
| 90 | + |
| 91 | +  |
| 92 | + |
| 93 | +9. From the *Certificates & secrets* page: |
| 94 | + |
| 95 | + 1. Select the **Client secrets** tab item |
| 96 | + |
| 97 | + 2. Click the **New client secret** button |
| 98 | + |
| 99 | + 3. From the *Add a client secret* pop-up: |
| 100 | + |
| 101 | + 1. Enter a **Description** and desired expiration |
| 102 | + |
| 103 | + 2. Click **Add** |
| 104 | + |
| 105 | + 4. Verify the new client secret appears |
| 106 | + |
| 107 | + 5. Click the **Copy** button for the *Value* of the newly created secret. Save this securely for use later, this value is only shown one time. |
| 108 | + |
| 109 | +  |
| 110 | + |
| 111 | +## Configure the Logic App |
| 112 | + |
| 113 | +1. From the Logic App, open the **Designer** view |
| 114 | + |
| 115 | +2. Select a desired trigger (if prompted) |
| 116 | + |
| 117 | +3. Add a new step and select the **HTTP** operation |
| 118 | + |
| 119 | +  |
| 120 | + |
| 121 | +4. In the operation details: |
| 122 | + |
| 123 | + 1. *Method*: Select the desired HTTP method to be sent to the internal API |
| 124 | + |
| 125 | + 2. *URI*: Fill in with the *public* FQDN of your application registered in Azure AD, along with the additional URI required for API access (e.g. *sampleapp1.msappproxy.net/api/1/status*) |
| 126 | + |
| 127 | + > [!NOTE] |
| 128 | + > Specific values for API will depend on your internal application. Refer to your application's documentation for more information. |
| 129 | +
|
| 130 | + 3. *Headers*: Enter any desired headers to be sent to the internal API |
| 131 | + |
| 132 | + 4. *Queries*: Enter any desired queries to be sent to the internal API |
| 133 | + |
| 134 | + 5. *Body*: Enter any desired body contents to be sent to the internal API |
| 135 | + |
| 136 | + 6. *Cookie*: Enter any desired cookie(s) to be sent to the internal API |
| 137 | + |
| 138 | + 7. Click *Add new parameter*, then check *Authentication* |
| 139 | + |
| 140 | + 8. From the *Authentication type*, select *Active Directory OAuth* |
| 141 | + |
| 142 | + 9. For the authentication, fill the following details: |
| 143 | + |
| 144 | + 1. *Authority*: Enter *https://login.windows.net* |
| 145 | + |
| 146 | + 2. *Tenant*: Enter the **Directory (tenant) ID** noted in *Configure the Application Access* |
| 147 | + |
| 148 | + 3. *Audience*: Enter the *public* FQDN of your application registered in Azure AD (e.g. *sampleapp1.msappproxy.net*) |
| 149 | + |
| 150 | + 4. *Client ID*: Enter the **Application (client) ID** noted in *Configure the Application Access* |
| 151 | + |
| 152 | + 5. *Credential Type*: **Secret** |
| 153 | + |
| 154 | + 6. *Secret*: Enter the **secret value** noted in *Configure the Application Access* |
| 155 | + |
| 156 | +  |
| 157 | + |
| 158 | +5. Save the logic app and test with your trigger |
| 159 | + |
| 160 | +## Caveats |
| 161 | + |
| 162 | +- APIs that require authentication/authorization require special handling when using this method. Since Azure Active Directory OAuth is being used for access, the requests sent already contain an *Authorization* field that cannot also be utilized by the internal API (unless SSO is configured). As a workaround, some applications offer authentication or authorization that uses methods other than an *Authorization* header. For example, GitLab allows for a header titled *PRIVATE-TOKEN*, and Atlassian JIRA allows for requesting a Cookie that can be used in later requests |
| 163 | + |
| 164 | +- While the Logic App HTTP action shows cleartext values, it is highly recommended to store the App Registration Secret Key in Azure Key Vault for secure retrieval and use. |
| 165 | + |
| 166 | +## See Also |
| 167 | + |
| 168 | +- [How to configure an Application Proxy application](./application-proxy-config-how-to.md) |
| 169 | +- [Access on-premises APIs with Azure Active Directory Application Proxy](./application-proxy-secure-api-access.md) |
| 170 | +- [Common scenarios, examples, tutorials, and walkthroughs for Azure Logic Apps](../../logic-apps/logic-apps-examples-and-scenarios.md) |
0 commit comments