使用权利管理中的自定义扩展触发逻辑应用

使用 Azure 逻辑应用可以自动化自定义工作流,并在一个位置连接应用和服务。 用户可将逻辑应用与权利管理相集成,将其治理工作流延伸到核心权利管理用例的范围之外。

然后可以触发这些逻辑应用以根据权利管理用例(例如在授予或请求访问包时)运行。 例如,管理员可以创建自定义逻辑应用并将其关联到权利管理,以便在用户请求访问包时触发逻辑应用,确保在第三方 SAAS 应用(如 Salesforce)中也可为该用户分配某些特征或向其发送自定义电子邮件。

可与逻辑应用集成的权利管理用例包括以下阶段。 以下是与可启动自定义扩展逻辑应用的访问包关联的触发时机:

  • 创建访问包请求时

  • 批准访问包请求时

  • 授权访问包分配时

  • 移除访问包分配时

  • 访问包分配自动过期前 14 天

  • 访问包分配自动过期前 1 天

逻辑应用的这些触发时机在称作“规则”的访问包策略内的新选项卡中进行控制。 此外,“目录”页面上的“自定义扩展”选项卡将显示为给定目录添加的所有逻辑应用扩展。 本文介绍如何在权限管理中创建逻辑应用并将其添加到目录和访问包。

许可要求

使用此功能需要 Microsoft Entra ID 治理或 Microsoft Entra 套件许可证。 如需查找符合要求的许可证,请参阅《Microsoft Entra ID 治理许可基础知识》。

创建逻辑应用工作流并将其添加到目录,以便在权利管理中使用

提示

本文中的步骤可能因开始使用的门户而略有不同。

  1. 至少以标识治理管理员身份登录到 Microsoft Entra 管理中心

    提示

    可以完成此任务的其他最低特权角色包括目录所有者和资源组所有者。

  2. 浏览到“标识治理”“目录”。

  3. 选择要为其添加自定义扩展的目录,然后在左侧菜单中选择“自定义扩展”。

  4. 在标题导航栏中,选择“添加自定义扩展”。

  5. 在“基本”选项卡中,输入自定义扩展的名称(该名称应为所关联逻辑应用的名称),以及关于工作流的说明。 这些字段将显示在“目录”页面的“自定义扩展”选项卡中。

    用于创建自定义扩展的窗格

  6. “扩展类型”选项卡将定义可以使用该自定义扩展的访问包策略的类型。 “请求工作流”类型支持以下策略阶段:创建请求的访问包时、批准请求时、授权分配时以及移除分配时。 此类型还支持启动并等待功能。

  7. 过期前工作流支持以下策略阶段:访问包分配到期前 14 天,以及访问包分配过期前 1 天。 此扩展类型不支持“启动并等待”。

    “启动并等待”配置选项的屏幕截图。

  8. 通过“扩展配置”选项卡,可以决定扩展是具有“启动并继续”行为,还是“启动并等待”行为。 如果选择“启动并继续”,访问包上的关联策略操作(如请求)会触发关联到自定义扩展的逻辑应用。 触发逻辑应用后,与访问包关联的权利管理过程将继续。 如果是“启动并等待”,我们将暂停关联的访问包操作,直到与扩展关联的逻辑应用完成其任务且管理员发送恢复操作,然后该过程才会继续。 如果未在定义的等待时间段内发送回响应,则此过程将被视为失败。 专门有一个部分详细介绍了此过程:配置将暂停权利管理过程的自定义扩展

  9. 在“详细信息”选项卡中,选择是否要使用现有的消耗计划逻辑应用。 如果在“创建新逻辑应用”字段中选择“是”(默认),将新建已关联到此自定义扩展的空白消耗计划逻辑应用。 无论如何,都需要提供:

    1. Azure 订阅。

    2. 具有逻辑应用资源创建权限的资源组(如果要创建新的逻辑应用)。

    3. 如果使用以下设置,请选择“创建逻辑应用”。

      有关创建逻辑应用的详细选择的屏幕截图。

    注意

    在此模式下新建逻辑应用时,"/subscriptions/{SubscriptionId}/resourceGroups/{RG Name}/providers/Microsoft.Logic/workflows/{Logicapp Name}" 的长度不能超过 150 个字符。

  10. 在“审阅并创建”中,查看自定义扩展的摘要,确保逻辑应用标注详细信息正确无误。 然后选择“创建”。

  11. 所关联逻辑应用的此自定义扩展现在会显示在“目录”下的“自定义扩展”选项卡中。 你可以在访问包策略中调用该自定义扩展。

查看和编辑目录的现有自定义扩展

  1. 如之前所述,至少以标识治理管理员的身份导航到“目录”中的“自定义扩展”选项卡。

    提示

    可以完成此任务的其他最低特权角色包括目录所有者。

  2. 在这里,可以查看已创建的所有自定义扩展,以及关联的逻辑应用和有关自定义扩展类型的信息。 自定义扩展列表的屏幕截图。

  3. “类型”列与逻辑应用名称一起指示自定义扩展是在新 V2 身份验证模型(2023 年 3 月 17 日之后)还是原始模型中创建的。 如果自定义扩展是在新模型中创建的,“类型”列将匹配配置模式中的所选类型,即“分配请求”或“过期前”。 对于较旧的自定义扩展,类型将显示为“自定义访问包”。

  4. “令牌安全性”列将显示创建自定义扩展时使用的关联身份验证安全框架。 新的 V2 自定义扩展将显示令牌安全类型为“所有权证明”(PoP)。 较旧的自定义扩展则将显示类型为“常规”。

  5. 你无法再从 UI 创建旧式的自定义扩展,但可以在 UI 上将现有的自定义扩展转换为新式自定义扩展。 将旧安全令牌转换为新令牌的屏幕截图。

  6. 通过选择旧自定义扩展所在行末尾的三个点,你可以快速将自定义扩展更新为新类型。

    注意

    自定义扩展只有在未使用时,或者在仅用于某一个特定扩展类型的策略阶段(分配请求阶段或过期前阶段)时,才能转换为新类型。

  7. 你还可以编辑任何自定义扩展。 这使你可以更新名称、说明和其他字段值。 该操作可以通过在任何自定义扩展的三点窗格中选择“编辑”来实现。

  8. 你无法再创建旧式的自定义扩展,但现有的旧式自定义扩展即使没有进行转换,也可以继续使用和进行编辑。

  9. 如果旧式自定义扩展由于正在 同时 用于分配请求和过期前两种类型的策略阶段而无法更新为新类型,则为了更新该扩展,必须将其从所有关联的策略中移除,或者确保其仅用于与 一种 类型(分配请求或过期前)关联的策略阶段。  

将自定义扩展添加到访问包中的策略

  1. 至少以标识治理管理员身份登录到 Microsoft Entra 管理中心

    提示

    可以完成此任务的其他最低特权角色包括目录所有者和访问包管理员。

  2. 浏览到“标识治理”>“权利管理”>“访问包”。

  3. 从已创建的访问包列表中选择要将自定义扩展(逻辑应用)添加到的访问包。

    注意

    如果你希望创建新的访问包,请选择“新建访问包”。 有关如何创建访问包的详细信息,请参阅在权利管理中创建新的访问包。 有关如何编辑现有访问包的详细信息,请参阅在 Microsoft Entra 权利管理中更改访问包的请求设置

  4. 切换到策略选项卡,选择该策略并选择“编辑”。

  5. 在策略设置中,转到“自定义扩展”选项卡。

  6. 在“阶段”下方的菜单中,选择要用作此自定义扩展(逻辑应用)的触发器的访问包事件。 例如,如果你只想在用户请求访问包时触发自定义扩展逻辑应用工作流,请选择“创建了请求时”。

  7. 在“自定义扩展”下方的菜单中,选择要添加到访问包的自定义扩展(逻辑应用)。 当在“何时”字段中选择的事件发生时,将执行你选择的操作。

  8. 选择“更新”以将其添加到现有访问包的策略。

    将逻辑应用添加到访问包

编辑链接逻辑应用的工作流定义

在创建新的关联到自定义扩展的逻辑应用时,这些逻辑应用在开始时是空白的。 若要在逻辑应用中创建将在触发关联访问包策略条件时由相应扩展触发的工作流,你需要在逻辑应用设计器中编辑逻辑应用工作流的定义。 若要完成此操作,请执行以下步骤:

  1. 如前所述,至少以标识治理管理员的身份导航到“目录”中的“自定义扩展”选项卡。

    提示

    可以完成此任务的其他最低特权角色包括目录所有者。

  2. 选择要为其编辑逻辑应用的自定义扩展。

  3. 在“逻辑应用”列下,为关联的自定义扩展行选择逻辑应用。 这样,你就可以在逻辑应用设计器中编辑或创建工作流。

有关创建逻辑应用工作流的详细信息,请参阅快速入门:在多租户 Azure 逻辑应用中创建示例使用量工作流

配置可暂停权利管理过程的自定义扩展

自定义扩展功能的一个新更新是能够暂停与自定义扩展关联的访问包策略过程,直到该逻辑应用完成且将恢复请求有效负载发送回权利管理才会恢复。 例如,如果逻辑应用的自定义扩展是从访问包授权策略触发的,并且启用了“启动并等待”,那么在触发该逻辑应用后,直到该逻辑应用完成且将恢复请求发送回权利管理,才会恢复授权过程。

此暂停过程使管理员能够控制他们想要运行的工作流,然后再继续在权利管理中访问生命周期任务。 唯一的例外是发生超时的情况。 “启动并等待”过程需要最多 14 天的超时(以分钟、小时或天为单位)。 如果未在“超时”期限过去前将恢复响应发送回权利管理,权利管理请求工作流进程会暂停。

管理员负责配置一个自动化过程,该过程能够在逻辑应用工作流完成后,将 API 恢复请求有效负载发送回权利管理。 若要发送回恢复请求有效负载,请按照图形 API 文档中的说明进行操作。 请参阅此处,查看有关恢复请求的信息。

具体而言,当启用访问包策略来调用自定义扩展,并且请求处理正在等待客户的回调时,客户可以启动恢复操作。 它在 requestStatus 处于 WaitingForCallback 状态的 accessPackageAssignmentRequest 对象上执行。

可以在以下阶段发送回恢复请求:

microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestCreated
microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestApproved
microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestGranted
microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestRemoved

以下流程图显示了逻辑应用工作流的权利管理标注:逻辑应用工作流的授权管理调用示意图。

流程图显示:

  1. 用户创建一个能够接收来自标识服务的调用的自定义终结点
  2. 标识服务执行测试调用,确认终结点可由标识服务调用
  3. 用户调用图形 API 以请求将用户添加到访问包
  4. 标识服务被添加到触发后端工作流的队列中
  5. 权利管理服务请求处理使用请求有效负载调用逻辑应用
  6. 工作流需要接受的代码
  7. 权利管理服务等待阻止自定义操作恢复
  8. 客户系统将请求恢复 API 调用到标识服务来恢复请求的处理
  9. 标识服务将恢复请求消息添加到恢复后端工作流的权利管理服务队列
  10. 权利管理服务从阻止状态恢复

恢复请求有效负载的一个示例是:

POST https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackageAssignmentRequests/00aa00aa-bb11-cc22-dd33-44ee44ee44ee/resume
Content-Type: application/json

{
  "source": "Contoso.SodCheckProcess",
  "type": "microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestCreated",
  "data": {
    "@odata.type": "microsoft.graph.accessPackageAssignmentRequestCallbackData",
    "stage": "assignmentRequestCreated",
    "customExtensionStageInstanceId": "957d0c50-466b-4840-bb5b-c92cea7141ff",
    "customExtensionStageInstanceDetail": "This user is all verified"
  }
}

通过选择“启动并等待”,管理员还可以在扩展关联到访问包阶段“请求已创建”或“请求已批准”时拒绝请求。 在这些情况下,逻辑应用可以将“拒绝”消息发送回权利管理,这将在最终用户收到访问包之前结束该过程。

如前所述,如果需要,可以使用“启动并等待”启用使用请求工作流类型创建的自定义扩展(包括四个关联的策略阶段)。

以下示例将通过拒绝正在等待回调的请求来恢复对访问包分配请求的处理。 系统无法在标注的 assignmentRequestCreated 阶段拒绝请求。

提示

如果通过 Azure 逻辑应用继续访问包分配请求,请禁用异步模式

POST https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackageAssignmentRequests/9e60f18c-b2a0-4887-9da8-da2e30a39d99/resume
Content-Type: application/json

{
  "source": "Contoso.SodCheckProcess",
  "type": "microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestCreated",
  "data": {
    "@odata.type": "microsoft.graph.accessPackageAssignmentRequestCallbackData",
    "stage": "AssignmentRequestCreated",
    "customExtensionStageInstanceId": "857d0c50-466b-4840-bb5b-c92cea7141ff",
    "state": "denied",
    "customExtensionStageInstanceDetail": "Potential risk user based on the SOD check"
  }
}

扩展最终用户体验

审批者体验

审批者在 customExtensionStageInstanceDetail 下看到恢复请求有效负载中指定的字符串, 如 配置暂停权利管理进程的自定义扩展 中的有效负载所示。 审批者屏幕的屏幕截图。

请求者体验

当访问包包含具有启动和等待功能的自定义扩展,并在创建访问包请求时触发逻辑应用时,请求者可以在 MyAccess 中的请求历史记录中查看其请求状态。

根据用户的自定义扩展阶段向用户显示以下状态更新:

自定义扩展阶段 在 MyAccess 请求历史记录中向请求者显示的消息
处理扩展时 等待信息,然后再继续
扩展失败时 进程已过期
扩展恢复时 进程继续

下面是扩展恢复后请求者的 MyAccess 请求历史记录示例:

请求者屏幕的屏幕截图。

故障排除和验证

对于与请求关联的自定义扩展,可以通过关联访问包的请求详细信息页面中的“请求历史记录详细信息”链接查看有关自定义扩展以及“启动并等待”(如果已启用)过程的详细信息。

自定义任务扩展的请求历史记录的屏幕截图。自定义任务扩展的选择详细信息的屏幕截图。

例如,可在此处查看提交请求的时间,以及“启动并等待”过程(等待回调)开始的时间。 在中午 12:15 执行逻辑应用并返回恢复请求后,请求已获批准,并且权利管理阶段“已恢复”。

此外,请求详细信息中新增的“自定义扩展实例链接”将显示有关与请求的访问包关联的自定义扩展的信息。
选择详细信息列表项的屏幕截图。

这会显示自定义扩展 ID 和状态。 此信息将根据是否存在关联的“启动并等待”回调而有所变化。

若要验证自定义扩展是否已正确触发关联的逻辑应用,你还可以查看逻辑应用日志,其中包含可表明上次执行逻辑应用的时间的时间戳。

后续步骤