You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory/governance/configure-logic-app-lifecycle-workflows.md
+63-11Lines changed: 63 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ author: owinfreyATL
5
5
ms.author: owinfrey
6
6
ms.service: active-directory
7
7
ms.topic: reference
8
-
ms.date: 01/26/2023
8
+
ms.date: 03/17/2023
9
9
ms.custom: template-how-to
10
10
---
11
11
@@ -15,16 +15,32 @@ ms.custom: template-how-to
15
15
16
16
Before you can use an existing Azure Logic App with the custom task extension feature of Lifecycle Workflows, it must first be made compatible. This reference guide provides a list of steps that must be taken to make the Azure Logic App compatible. For a guide on creating a new compatible Logic App via the Lifecycle Workflows portal, see [Trigger Logic Apps based on custom task extensions (preview)](trigger-custom-task.md).
17
17
18
+
## Determine type of token security of your custom task extension
19
+
20
+
Before configuring your Azure Logic App custom extension for use with Lifecycle Workflows, you must first figure out what type of token security it has. The two token security types can either be:
21
+
22
+
- Normal
23
+
- Proof of Possession(POP)
24
+
25
+
26
+
To determine the security token type of your custom task extension, you'd check the **Custom extensions (Preview)** page:
27
+
28
+
:::image type="content" source="media/configure-logic-app-lifecycle-workflows/custom-task-extension-token-type.png" alt-text="Screenshot of custom task extension and token type.":::
29
+
30
+
31
+
> [!NOTE]
32
+
> New custom task extensions will only have Proof of Possession(POP) token security type. Only task extensions created before the inclusion of the Proof of Possession token security type will have a type of Normal.
33
+
18
34
## Configure existing Logic Apps for LCW use
19
35
20
36
Making an Azure Logic app compatible to run with the **Custom Task Extension** requires the following steps:
21
37
22
38
- Configure the logic app trigger
23
-
- Configure the callback action (only applicable to the callback scenario)
24
-
- Enable system assigned managed identity.
25
-
- Configure AuthZ policies.
39
+
- Configure the callback action (Only applicable to the callback scenario.)
40
+
- Enable system assigned managed identity (Always required for Normal security token type extensions. This is also the default for callback scenarios with custom task extensions. For more information on this, and other, custom task extension deployment scenarios, see: [Custom task extension deployment scenarios](lifecycle-workflow-extensibility.md#custom-task-extension-deployment-scenarios).)
41
+
- Configure AuthZ policies
26
42
27
-
To configure those you'll follow these steps:
43
+
To configure those you follow these steps:
28
44
29
45
1. Open the Azure Logic App you want to use with Lifecycle Workflow. Logic Apps may greet you with an introduction screen, which you can close with the X in the upper right corner.
30
46
@@ -202,21 +218,59 @@ To configure those you'll follow these steps:
202
218
203
219
1. Select Save.
204
220
205
-
1. For Logic Apps authorization policy, we'll need the managed identities **Application ID**. Since the Azure portal only shows the Object ID, we need to look up the Application ID. You can search for the managed identity by Object ID under **Enterprise Applications in the Azure portal** to find the required Application ID.
221
+
## Configure authorization policy for custom task extension with POP security token type
222
+
If the security token type is **Proof of Possession (POP)** for your custom task extension, you'd set the authorization policy by following these steps:
223
+
224
+
1. For Logic Apps authorization policy, we need the managed identities **Application ID**. Since the Azure portal only shows the Object ID, we need to look up the Application ID. You can search for the managed identity by Object ID under **Enterprise Applications in the Azure AD Portal** to find the required Application ID.
206
225
207
226
1. Go back to the logic app you created, and select **Authorization**.
208
227
209
-
1. Create two authorization policies based on the tables below:
228
+
1. Create two authorization policies based on these tables:
> Please pay attention to the details as minor differences can lead to problems later.
248
+
- For Issuer, ensure you did include the slash after your Tenant ID
249
+
- For appid, ensure the custom claim is “appid” in all lowercase. The appid value represents Lifecycle Workflows and is always the same.
250
+
251
+
## Configure authorization policy for custom task extension with normal security token type
252
+
253
+
If the security token type is **Normal** for your custom task extension, you'd set the authorization policy by following these steps:
254
+
255
+
1. For Logic Apps authorization policy, we need the managed identities **Application ID**. Since the Azure portal only shows the Object ID, we need to look up the Application ID. You can search for the managed identity by Object ID under **Enterprise Applications in the Azure AD Portal** to find the required Application ID.
256
+
257
+
1. Go back to the logic app you created, and select **Authorization**.
258
+
259
+
1. Create two authorization policies based on these tables:
260
+
261
+
Policy name: AzureADLifecycleWorkflowsAuthPolicy
262
+
263
+
Policy type: AAD
212
264
213
265
|Claim |Value |
214
266
|---------|---------|
215
267
|Issuer | https://sts.windows.net/(Tenant ID)/ |
216
268
|Audience | Application ID of your Logic Apps Managed Identity |
Copy file name to clipboardExpand all lines: articles/active-directory/governance/entitlement-management-logic-apps-integration.md
+17-4Lines changed: 17 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -70,7 +70,7 @@ These triggers to Logic Apps are controlled in a tab within access package polic
70
70
1. The **Extension Configuration** tab allows you to decide if your extension has “launch and continue” or “launch and wait” behavior. With “Launch and continue” the linked policy action on the access package, such as a request, triggers the Logic App attached to the custom extension. After the Logic App is triggered, the entitlement management process associated with the access package will continue. For “Launch and wait”, we'll pause the associated access package action until after the Logic App linked to the extension completes its task, and a resume action is sent by the admin to continue the process. If no response is sent back in the wait time period defined, this process would be considered a failure. This process is further described below in its own section [Configuring custom extensions that pause entitlement management processes](entitlement-management-logic-apps-integration.md#configuring-custom-extensions-that-pause-entitlement-management-processes).
71
71
72
72
73
-
1. In the **Details** tab, choose whether you’d like to use an existing Logic App. Selecting Yes in the field “Create new logic app” (default) creates a new blank Logic App that is already linked to this custom extension. Regardless, you need to provide:
73
+
1. In the **Details** tab, choose whether you’d like to use an existing consumption plan Logic App. Selecting Yes in the field “Create new logic app” (default) creates a new blank consumption plan Logic App that is already linked to this custom extension. Regardless, you need to provide:
74
74
75
75
1. An Azure subscription.
76
76
@@ -161,7 +161,7 @@ A new update to the custom extensions feature is the ability to pause the access
161
161
162
162
This pause process allows admins to have control of workflows they’d like to run before continuing with access lifecycle tasks in entitlement management. The only exception to this is if a timeout occurs. Launch and wait processes require a timeout of up to 14 days noted in minutes, hours, or days. If a resume response isn't sent back to entitlement management by the time the “timeout” period elapses, the entitlement management request workflow process pauses.
163
163
164
-
The admin is responsible for configuring an automated process that is able to send the API **resume request** payload back to entitlement management, once the Logic App workflow has completed. To send back the resume request payload, follow the instructions here in the graph API documents. See information here on the [resume request](/graph/api/accesspackageassignmentrequest-resume)
164
+
The admin is responsible for configuring an automated process that is able to send the API **resume request** payload back to entitlement management, once the Logic App workflow has completed. To send back the resume request payload, follow the instructions here in the graph API documents. See information here on the [resume request](/graph/api/accesspackageassignmentrequest-resume).
165
165
166
166
Specifically, when an access package policy has been enabled to call out a custom extension and the request processing is waiting for the callback from the customer, the customer can initiate a resume action. It's performed on an [accessPackageAssignmentRequest](/graph/api/resources/accesspackageassignmentrequest) object whose **requestStatus** is in a **WaitingForCallback** state.
167
167
@@ -171,12 +171,25 @@ The resume request can be sent back for the following stages:
The following flow diagram shows the entitlement management callout to Logic Apps workflow:
178
-
:::image type="content" source="media/entitlement-management-logic-apps/extensibility-diagram-flow.png" alt-text="A screenshot of the extensibility user diagram." lightbox="media/entitlement-management-logic-apps/extensibility-diagram-flow.png":::
178
+
:::image type="content" source="media/entitlement-management-logic-apps/extensibility-diagram-flow.png" alt-text="A diagram of the entitlement management call to the logic apps workflow." lightbox="media/entitlement-management-logic-apps/extensibility-diagram-flow.png":::
179
179
180
+
The diagram flow diagram shows:
181
+
182
+
1. The user creates a custom endpoint able to receive the call from the Identity Service
183
+
1. The identity service makes a test call to confirm the endpoint can be called by the Identity Service
184
+
1. The User calls Graph API to request to add a user to an access package
185
+
1. The Identity Service is added to the queue triggering the backend workflow
186
+
1. Entitlement Management Service request processing calls the logic app with the request payload
187
+
1. Workflow expects the accepted code
188
+
1. The Entitlement Management Service waits for the blocking custom action to resume
189
+
1. The customer system calls the request resume API to the identity service to resume processing the request
190
+
1. The identity service adds the resume request message to the Entitlement Management Service queue resuming the backend workflow
191
+
1. The Entitlement Management Service is resumed from the blocked state
0 commit comments