你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证
适用范围:Azure 逻辑应用(消耗型 + 标准型)
如果不希望提供、存储和管理凭据、机密或 Microsoft Entra 令牌,可以使用托管标识对逻辑应用工作流对受 Microsoft Entra 保护的资源的访问或连接进行身份验证。 在 Azure 逻辑应用中,当你必须对受 Microsoft Entra ID 保护的资源的访问进行身份验证时,某些连接器操作支持使用托管标识。 Azure 负责管理此标识并帮助保护身份验证信息的安全,这样你就无需管理这种敏感信息了。 有关详细信息,请参阅什么是 Azure 资源的托管标识?
Azure 逻辑应用支持以下托管标识类型:
以下列表描述了这些托管标识类型之间的一些差异:
逻辑应用资源只能启用和使用一个系统分配的唯一标识。
逻辑应用资源可以在其他逻辑应用资源组中共享相同的用户分配的标识。
本指南演示如何完成以下任务:
为逻辑应用资源启用和设置系统分配的标识。 本指南提供了一个示例,演示如何使用标识进行身份验证。
创建并设置用户分配的标识。 本指南演示了如何使用 Azure 门户或 Azure 资源管理器模板(ARM 模板)创建此标识,以及如何使用标识进行身份验证。 对于 Azure PowerShell、Azure CLI 和 Azure REST API,请参阅以下文档:
工具 文档 Azure PowerShell 创建用户分配的标识 Azure CLI 创建用户分配的标识 Azure REST API 创建用户分配的标识
先决条件
Azure 帐户和订阅。 如果没有订阅,可以注册免费的 Azure 帐户。 托管标识和需要访问的目标 Azure 资源必须使用相同的 Azure 订阅。
要访问的目标 Azure 资源。 在此资源上,你必须为托管标识添加必要的角色,以代表逻辑应用或连接访问该资源。 若要向托管标识添加角色,你需要具有 Microsoft Entra 管理员权限,这些权限可以将角色分配给相应的 Microsoft Entra 租户中的标识。
要在其中使用支持托管标识的触发器或操作的逻辑应用资源或工作流。
消耗逻辑应用与标准逻辑应用之间的托管标识差异
根据逻辑应用资源类型,你可以启用系统分配的标识、用户分配的标识或同时启用这两种标识:
逻辑应用 | 环境 | 托管标识支持 |
---|---|---|
消耗 | - 多租户 Azure 逻辑应用 | - 可以启用系统分配的标识或用户分配的标识,但不能在逻辑应用上同时启用二者。 - 可以在逻辑应用资源级别和连接级别使用托管标识。 - 如果创建并启用用户分配的标识,逻辑应用一次只能有一个用户分配的标识。 |
Standard | - 单租户 Azure 逻辑应用 - 应用服务环境 v3 (ASEv3) - 已启用 Azure Arc 的逻辑应用 |
- 可以同时启用系统分配的标识(默认启用)和用户分配的标识。 还可以将多个用户分配的标识添加到逻辑应用。 但是,逻辑应用一次只能使用一个托管标识。 - 可以在逻辑应用资源级别和连接级别使用托管标识。 |
有关 Azure 逻辑应用中的托管标识限制的信息,请参阅逻辑应用的托管标识限制。 有关消耗和标准逻辑应用资源类型和环境的详细信息,请参阅以下文档:
可以使用托管标识的操作
在 Azure 逻辑应用中,只有支持使用 Microsoft Entra ID 进行 OAuth 的特定内置和托管连接器操作才能使用托管标识进行身份验证。 下面的表仅提供了一个示例选择。 有关更完整的列表,请参阅以下文档:
对于消耗逻辑应用工作流,下表列出了支持托管标识身份验证的连接器示例:
连接器类型 | 受支持的连接器 |
---|---|
内置 | - Azure API 管理 - Azure 应用服务 - Azure Functions - HTTP - HTTP + Webhook 注意:HTTP 操作可使用系统分配的标识验证与 Azure 防火墙后面的 Azure 存储帐户的连接。 但是,HTTP 操作不支持使用用户分配的标识对上述连接进行身份验证。 |
托管 | - Azure 应用服务 - Azure 自动化 - Azure Blob 存储 - Azure 容器实例 - Azure Cosmos DB - Azure 数据资源管理器 - Azure 数据工厂 - Azure Data Lake - Azure 数字孪生 - Azure 事件网格 - Azure 事件中心 - Azure IoT Central V2 - Azure 密钥保管库 - Azure Monitor 日志 - Azure 队列 - Azure 资源管理器 - Azure 服务总线 - Azure Sentinel - Azure 表存储 - Azure VM - SQL Server |
在 Azure 门户中启用系统分配的标识
在消耗逻辑应用资源上,必须手动启用系统分配的标识。
在 Azure 门户中,打开你的消耗逻辑应用资源。
在逻辑应用菜单的“设置”下,选择“标识” 。
在“标识”页的“系统分配的”下,选择“开”>“保存”。 当 Azure 提示你进行确认时,选择“是”。
注意
如果收到一个错误,指出你只能有一个托管标识,则表明逻辑应用资源已与用户分配的标识相关联。 在添加系统分配的标识之前,必须先从逻辑应用资源中删除用户分配的标识。
逻辑应用资源现在可以使用系统分配的标识。 此标识已注册到 Microsoft Entra ID,通过对象 ID 表示。
属性 价值 说明 对象(主体) ID <identity-resource-ID> 全局唯一标识符 (GUID),表示 Microsoft Entra 租户中逻辑应用的系统分配的标识。 现在,请执行本指南后面的为系统分配的标识授予对资源的访问权限的步骤。
在 ARM 模板中启用系统分配的标识
要自动创建并部署逻辑应用资源,可以使用 ARM 模板。 若要在模板中为逻辑应用资源启用系统分配的标识,请在模板中将 identity 对象和 type 子属性添加到逻辑应用的资源定义中,例如:
{
"apiVersion": "2016-06-01",
"type": "Microsoft.logic/workflows",
"name": "[variables('logicappName')]",
"location": "[resourceGroup().location]",
"identity": {
"type": "SystemAssigned"
},
"properties": {},
<...>
}
当 Azure 创建逻辑应用资源定义时,identity 对象会获取以下其他属性:
"identity": {
"type": "SystemAssigned",
"principalId": "<principal-ID>",
"tenantId": "<Entra-tenant-ID>"
}
属性 (JSON) | 值 | 说明 |
---|---|---|
principalId | <principal-ID> | 托管标识的服务主体对象的全局唯一标识符 (GUID),表示 Microsoft Entra 租户中的逻辑应用。 此 GUID 有时显示为“对象 ID”或 objectID。 |
tenantId | Microsoft-Entra-ID-tenant-ID<> | 全局唯一标识符 (GUID),表示逻辑应用现在是其中一名成员的 Microsoft Entra 租户。 在 Microsoft Entra 租户内,服务主体与逻辑应用实例具有相同名称。 |
在 Azure 门户中创建用户分配的标识
必须先将用户分配的标识创建为单独的 Azure 资源,才能在消耗逻辑应用资源或标准逻辑应用资源上启用该标识。
在 Azure 门户搜索框中输入“托管标识”。 在结果列表中,选择“托管标识”。
在“托管标识”页工具栏上,选择“创建”。
提供有关托管标识的信息,然后选择“查看 + 创建”,例如:
properties 需要 值 说明 订阅 是 <Azure-subscription-name> Azure 订阅名称 资源组 是 <Azure-resource-group-name> Azure 资源组名称。 创建新组或选择现有组。 此示例创建了名为“fabrikam-managed-identities-RG”的新组。 区域 是 <Azure-region> 用于存储有关资源的信息的 Azure 区域。 此示例使用“美国西部”。 名称 是 <user-assigned-identity-name> 赋予用户分配的标识的名称。 此示例使用“Fabrikam-user-assigned-identity”。 Azure 验证信息后会创建托管标识。 现在,可以将用户分配的标识添加到逻辑应用资源中。
将用户分配的标识添加到 Azure 门户的逻辑应用中
在 Azure 门户中,打开你的消耗逻辑应用资源。
在逻辑应用菜单的“设置”下,选择“标识” 。
在“标识”页上,选择“用户分配”,然后选择“添加”。
在“添加用户分配的托管标识”窗格上,请执行以下步骤:
从“选择订阅”列表中选择你的 Azure 订阅。
从具有你的订阅中的所有托管标识的列表中,选择所需的用户分配的标识。 若要筛选列表,请在“用户分配的托管标识”搜索框中输入标识或资源组的名称。
完成后,选择“添加”。
注意
如果你收到一个错误,指出你只能有一个托管标识,则表明逻辑应用已与系统分配的标识相关联。 在添加用户分配的标识之前,必须先禁用系统分配的标识。
你的逻辑应用现已与用户分配的标识相关联。
现在,请执行本指南后面的为标识授予对资源的访问权限的步骤。
在 ARM 模板中创建用户分配的标识
要自动创建并部署逻辑应用资源,可以使用 ARM 模板。 这些模板支持用于身份验证的用户分配的标识。
在模板的“资源”部分中,逻辑应用的资源定义需要以下各项:
type 属性设置为 UserAssigned 的 identity 对象
用于指定用户分配的资源和名称的子 userAssignedIdentities 对象
此示例显示了具有非参数化 identity 对象的 HTTP PUT 请求的消耗逻辑应用资源和工作流定义。 对 PUT 请求和后续的 GET 操作的响应还包含此 identity 对象:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {<template-parameters>},
"resources": [
{
"apiVersion": "2016-06-01",
"type": "Microsoft.logic/workflows",
"name": "[variables('logicappName')]",
"location": "[resourceGroup().location]",
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-assigned-identity-name>": {}
}
},
"properties": {
"definition": {<logic-app-workflow-definition>}
},
"parameters": {},
"dependsOn": []
},
],
"outputs": {}
}
如果模板还包括托管标识的资源定义,则可以将 identity 对象参数化。 以下示例显示了子 userAssignedIdentities 对象如何引用在模板“变量”部分中定义的 userAssignedIdentityName 变量。 此变量引用用户分配的标识的资源 ID。
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"Template_LogicAppName": {
"type": "string"
},
"Template_UserAssignedIdentityName": {
"type": "securestring"
}
},
"variables": {
"logicAppName": "[parameters(`Template_LogicAppName')]",
"userAssignedIdentityName": "[parameters('Template_UserAssignedIdentityName')]"
},
"resources": [
{
"apiVersion": "2016-06-01",
"type": "Microsoft.logic/workflows",
"name": "[variables('logicAppName')]",
"location": "[resourceGroup().location]",
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]": {}
}
},
"properties": {
"definition": {<logic-app-workflow-definition>}
},
"parameters": {},
"dependsOn": [
"[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]"
]
},
{
"apiVersion": "2018-11-30",
"type": "Microsoft.ManagedIdentity/userAssignedIdentities",
"name": "[parameters('Template_UserAssignedIdentityName')]",
"location": "[resourceGroup().location]",
"properties": {}
}
]
}
授予标识对资源的访问权限
必须先针对要使用逻辑应用的托管标识的目标 Azure 资源上的标识设置访问权限,才能使用该标识进行身份验证。 设置访问权限的方式因目标资源而异。
注意
当托管标识有权访问同一订阅中的 Azure 资源时,该标识只能访问该资源。 但是,在某些支持托管标识的触发器和操作中,你必须首先选择包含目标资源的 Azure 资源组。 如果标识在资源组级别没有访问权限,即使有权访问目标资源,该组中也不会列出任何资源。
若要处理此行为,还必须向标识授予对资源组的访问权限,而不只是对资源的访问权限。 同样,如果必须先选择订阅,然后才能选择目标资源,你必须向标识授予对订阅的访问权限。
在某些情况下,可能需要标识才能访问关联的资源。 例如,假设逻辑应用有一个托管标识,该标识需要访问权限才能从工作流更新同一逻辑应用的应用程序设置。 必须向该标识授予对关联逻辑应用的访问权限。
例如,若要使用托管标识访问 Azure Blob 存储帐户或 Azure 密钥保管库,则需要设置 Azure 基于角色的访问控制 (Azure RBAC),并将该标识的相应角色分别分配给存储帐户或密钥保管库。
本部分中的步骤介绍如何使用 Azure 门户和 Azure 资源管理器模板(ARM 模板)分配基于角色的访问。 对于 Azure PowerShell、Azure CLI 和 Azure REST API,请参阅以下文档:
工具 | 文档 |
---|---|
Azure PowerShell | 添加角色分配 |
Azure CLI | 添加角色分配 |
Azure REST API | 添加角色分配 |
对于 Azure 密钥保管库,你也可以在密钥保管库上为托管标识创建访问策略,并为该密钥保管库上的该标识分配相应权限。 本部分的后续步骤介绍如何使用 Azure 门户完成此任务。 对于资源管理器模板、PowerShell 和 Azure CLI,请参阅以下文档:
工具 | 文档 |
---|---|
Azure 资源管理器模板(ARM 模板) | Key Vault 访问策略资源定义 |
Azure PowerShell | 分配 Key Vault 访问策略 |
Azure CLI | 分配 Key Vault 访问策略 |
使用 Azure 门户分配对托管标识的基于角色的访问权限
若要使用托管标识进行身份验证,某些 Azure 资源(如 Azure 存储帐户)要求将标识分配给对目标资源具有相应权限的角色。 其他 Azure 资源(如 Azure 密钥保管库)支持多个选项,因此可以选择基于角色的访问或对该标识的目标资源具有适当权限的访问策略。
在 Azure 门户中,打开要使用标识的资源。
在资源菜单中,选择“访问控制(IAM)”>“添加”>“添加角色分配”。
注意
如果已禁用“添加角色分配”选项,那么你没有权限分配角色。 有关详细信息,请参阅 Microsoft Entra 内置角色。
将必要的角色分配给托管标识。 在“角色”选项卡上,分配一个角色,该角色将为标识提供访问当前资源所需的权限。
在本示例中,请分配名为“存储 Blob 数据参与者”的角色,该角色包含对 Azure 存储容器中 blob 的写入访问权限。 有关特定存储容器角色的详细信息,请参阅可以访问 Azure 存储容器中的 blob 的角色。
接下来,选择要分配角色的托管标识。 在“将访问权限分配到”下,选择“托管标识”>“添加成员”。
根据托管标识的类型,选择或提供以下值:
类型 Azure 服务实例 订阅 成员 系统分配 逻辑应用 <Azure-subscription-name> <your-logic-app-name> 用户分配 不适用 <Azure-subscription-name> <your-user-assigned-identity-name> 有关分配角色的更多信息,请参阅使用 Azure 门户分配角色。
完成后,可以使用此标识对支持托管标识的触发器和操作的访问权限进行身份验证。
有关此任务的更多常规信息,请参阅将托管标识访问权限分配给 Azure 资源或另一个资源。
使用 Azure 门户创建访问策略
若要使用托管标识进行身份验证,其他 Azure 资源还需要创建对该标识的目标资源具有相应权限的访问策略。 其他 Azure 资源(如 Azure 存储帐户)要求将标识分配给对目标资源具有相应权限的角色。
在 Azure 门户中,打开需要使用标识的目标资源。 本例使用 Azure 密钥保管库作为目标资源。
在资源菜单中,选择“访问策略”>“创建”,这将打开“创建访问策略”窗格。
在“权限”选项卡上,选择标识访问目标资源所需的权限。
例如,若要将标识与 Azure 密钥保管库托管连接器的“列出机密”操作一起使用,则标识需要“列出”权限。 因此,在“机密权限”列中,选择“列表”。
准备就绪后,选择“下一步”。 在“主体”选项卡上,找到并选择托管标识,该标识是本例中用户分配的标识。
跳过可选的“应用程序”步骤,选择“下一步”,然后完成创建访问策略。
下一部分展示了如何将托管标识和触发器或操作一起使用以对访问权限进行身份验证。 本示例将继续执行前文使用 RBAC 和 Azure 存储帐户为托管标识设置访问权限的步骤作为示例。 但是,使用托管标识进行身份验证的一般步骤都相同。
使用托管标识对访问权限进行身份验证
为逻辑应用资源启用托管标识并授予该标识对 Azure 目标资源或服务的访问权限后,可以在支持托管标识的触发器和操作中使用该标识。
重要
如果你有想要使用系统分配的标识的 Azure 函数,首先为 Azure 函数启用身份验证。
以下步骤演示了如何使用 Azure 门户将托管标识与触发器或操作一起使用。 若要在触发器或操作的基础 JSON 定义中指定托管标识,请参阅托管标识身份验证。
在 Azure 门户中,打开你的消耗逻辑应用资源。
如果尚未这样做,请添加支持托管标识的触发器或操作。
注意
并非所有连接器操作都支持你添加身份验证类型。 有关详细信息,请参阅支持身份验证的触发器和操作的身份验证类型。
在添加的触发器或操作上,执行以下步骤:
支持托管标识身份验证的内置连接器操作
这些步骤将继续使用 HTTP 操作作为示例。
如果“身份验证”属性尚未出现,则在“高级参数”列表中添加该属性。
现在,“身份验证”属性和“身份验证类型”列表都显示在操作上。
从“身份验证类型”列表中选择“托管标识”。
“身份验证”部分现在显示以下选项:
“托管标识”列表,可以从中选择特定的托管标识
“受众”属性显示在特定的触发器和操作上,以便为 Azure 目标资源或服务设置资源 ID。 否则,默认情况下,“受众”属性使用
https://management.azure.com/
资源 ID,该 ID 是 Azure 资源管理器的资源 ID。
从“托管标识”列表中,选择要使用的标识,例如:
注意
默认选中的选项是“系统分配的托管标识”(即使未启用任何托管标识)。
要成功使用某个托管标识,必须先在逻辑应用上启用该标识。 在消耗逻辑应用中,可以拥有系统分配的托管标识或用户分配的托管标识,但不能同时拥有二者。
有关详细信息,请参阅示例:使用托管标识对内置触发器或操作进行身份验证。
支持托管标识身份验证的托管连接器操作
在“创建连接”窗格的“身份验证”列表中,选择“托管标识”,例如:
在下一个窗格中,对于“连接名称”,为连接提供一个名称。
对于身份验证类型,根据托管连接器选择下列选项之一:
单一身份验证:这些连接器仅支持一种身份验证类型,在本例中,即仅支持托管标识。
从“托管标识”列表中,选择当前已启用的托管标识。
准备就绪后,选择“新建”。
多重身份验证:这些连接器支持多种身份验证类型,但一次只能选择和使用一种类型。
以下步骤将继续使用 Azure Blob 存储操作作为示例。
有关详细信息,请参阅示例:使用托管标识对托管连接器触发器或操作进行身份验证。
示例:使用托管标识对内置触发器或操作进行身份验证
内置 HTTP 触发器或操作可使用你在逻辑应用资源上启用的系统分配的标识。 通常,HTTP 触发器或操作使用以下属性来指定要访问的资源或实体:
属性 | 必选 | 说明 |
---|---|---|
方法 | 是 | 要运行的操作所使用的 HTTP 方法 |
URI | 是 | 用于访问目标 Azure 资源或实体的终结点 URL。 URI 语法通常包含目标 Azure 资源或服务的资源 ID。 |
标头 | 否 | 需要包含在传出请求中的任何标头值,如内容类型 |
查询 | 否 | 需要或希望包含在请求中的任何查询参数。 例如,针对特定操作的查询参数,或针对要运行的操作的 API 版本的查询参数。 |
身份验证 | 是 | 用于对 Azure 目标资源或服务的访问进行身份验证的身份验证类型 |
作为特定示例,假设要在之前为标识设置访问权限的 Azure 存储帐户中的 Blob 上运行快照 Blob 操作。 但是,Azure Blob 存储连接器当前不提供此操作。 相反,你可以使用 HTTP 操作或另一个 Blob 服务 REST API 操作来运行此操作。
重要
若要使用 Azure Blob 存储连接器和托管标识访问防火墙后的 Azure 存储帐户,请确保同时还设置了存储帐户,但也存在允许受信任的 Microsoft 服务访问的例外情况。
若要运行快照 Blob 操作,HTTP 操作将指定以下属性:
properties | 必选 | 示例值 | 说明 |
---|---|---|---|
URI | 是 | https://<storage-account-name>/<folder-name>/{name} |
Azure 全球(公共)环境中使用此语法的 Azure Blob 存储文件的资源 ID |
方法 | 是 | PUT |
快照 Blob 操作使用的 HTTP 方法 |
标头 | 对于 Azure 存储 | x-ms-blob-type = BlockBlob x-ms-version = 2024-05-05 x-ms-date = formatDateTime(utcNow(),'r') |
Azure 存储操作需要 x-ms-blob-type 、x-ms-version 和 x-ms-date 标头值。 重要说明:在 Azure 存储的传出 HTTP 触发器和操作请求中,标头需要 x-ms-version 属性以及要运行的操作的 API 版本。 x-ms-date 必须为当前日期。 否则,工作流将失败并显示 403 FORBIDDEN 错误。 若要获取所需格式的当前日期,可以在示例值中使用表达式。 有关详细信息,请参阅以下文档: - 请求标头 - 快照 Blob - Azure 存储服务的版本控制 |
查询 | 仅适用于快照 Blob 操作 | comp = snapshot |
操作的查询参数名称和值。 |
在工作流设计器上,添加所需的任何触发器,然后添加 HTTP 操作。
以下示例演示了一个示例 HTTP 操作,其中包含用于快照 Blob 操作的所有先前描述的属性值:
在 HTTP 操作中,添加“身份验证”属性。 从“高级参数”列表中选择“身份验证”。
“身份验证”部分现在显示在 HTTP 操作中。
注意
并非所有触发器和操作支持都允许你添加身份验证类型。 有关详细信息,请参阅支持身份验证的触发器和操作的身份验证类型。
从“身份验证类型”列表中选择“托管标识”。
从“托管标识”列表中,根据你的场景从可用选项中进行选择。
此示例将继续处理“系统分配的托管标识”。
在某些触发器和操作上,“受众”属性会显示,以便为目标 Azure 资源或服务设置资源 ID。
例如,若要对全局 Azure 云中密钥保管库资源的访问权限进行身份验证,则必须将“受众”属性具体设置为以下资源 ID:
https://vault.azure.net
如果不设置“受众”属性,默认情况下,“受众”属性使用
https://management.azure.com/
资源 ID,这是 Azure 资源管理器的资源 ID。重要
请确保该目标资源 ID 完全匹配 Microsoft Entra ID 所需的值。 否则,你可能会收到
400 Bad Request
错误或401 Unauthorized
错误。 因此,如果资源 ID 包含任何尾随斜杠,请确保将它们包含在内。 如果不包含尾随斜杠,则不要包含在内。例如,所有 Azure Blob 存储帐户的资源 ID 都需要尾部反斜杠。 但是,特定存储帐户的资源 ID 不需要尾部反斜杠。 请查看支持 Microsoft Entra ID 的 Azure 服务的资源 ID。
此示例将“受众”属性设置为
https://storage.azure.com/
,以便用于身份验证的访问令牌对所有存储帐户都有效。 但是,还可以为特定存储帐户指定根服务 URLhttps://<your-storage-account>.blob.core.windows.net
。有关使用适用于 Azure 存储的 Microsoft Entra ID 授权访问的详细信息,请参阅以下文档:
继续按照所需方式生成工作流。
示例:使用托管标识对托管连接器触发器或操作进行身份验证
Azure 资源管理器托管连接器有一个名为“读取资源”的操作,该操作可使用在逻辑应用资源上启用的托管标识。 此示例显示了如何将系统分配的托管标识与托管连接器结合使用。
在工作流设计器上,添加名为“读取资源”的 Azure 资源管理器操作。
在“创建连接”窗格的“身份验证”列表中选择“托管标识”,然后选择“登录”。
注意
在其他连接器中,“身份验证类型”列表会显示“逻辑应用托管标识”,因此请选择此选项。
为连接提供一个名称,然后选择要使用的托管标识。
如果你启用了系统分配的标识,“托管标识”列表将自动选择“系统分配的托管标识”。 反之,如果你启用了用户分配的标识,该列表会自动选择用户分配的标识。
在本例中,“系统分配的托管标识”是唯一可用的选择。
注意
如果在尝试创建或更改连接时未启用托管标识,或者在已启用托管标识的连接仍然存在时移除了托管标识,你会遇到一个错误,指出必须启用标识并授予对目标资源的访问权限。
准备就绪后,选择“新建”。
设计器成功创建连接后,设计器可使用托管标识身份验证获取任何动态值、内容或架构。
继续按照所需方式生成工作流。
逻辑应用资源定义和使用托管标识的连接
启用和使用托管标识的连接是一种特殊的连接类型,仅适用于托管标识。 在运行时,该连接使用逻辑应用资源上启用的托管标识。 Azure 逻辑应用会检查工作流中是否有任何托管连接器操作设置为使用托管标识,并且确认所有所需权限均存在以使用托管标识来访问由连接器操作指定的目标资源。 如果此检查成功,Azure 逻辑应用将检索与托管标识关联的 Microsoft Entra 令牌,使用该标识验证对目标 Azure 资源的访问,并在工作流中执行已配置的操作。
在消耗逻辑应用资源中,此连接配置保存在资源定义的 parameters
对象中,该对象包含 $connections
对象,后者包含指向连接的资源 ID 以及启用用户分配的标识时托管标识的资源 ID 的指针。
此示例显示了逻辑应用启用系统分配的标识时的 parameters
对象配置:
"parameters": {
"$connections": {
"value": {
"<action-name>": {
"connectionId": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>",
"connectionName": "<connector-name>",
"connectionProperties": {
"authentication": {
"type": "ManagedServiceIdentity"
}
},
"id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<managed-connector-type>"
}
}
}
}
此示例显示了逻辑应用启用用户分配的托管标识时的 parameters
对象配置:
"parameters": {
"$connections": {
"value": {
"<action-name>": {
"connectionId": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>",
"connectionName": "<connector-name>",
"connectionProperties": {
"authentication": {
"type": "ManagedServiceIdentity",
"identity": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/microsoft.managedidentity/userassignedidentities/<managed-identity-name>"
}
},
"id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<managed-connector-type>"
}
}
}
}
用于 API 连接和托管标识的 ARM 模板
如果你使用 ARM 模板自动执行部署,并且工作流中包含 API 连接,该连接由使用托管标识的托管连接器创建,那么你需要执行一个额外的步骤。
在 ARM 模板中,基础连接器资源定义会有所不同,具体取决于使用的是消耗逻辑应用资源还是标准逻辑应用资源,以及连接器是显示单一身份验证选项还是多重身份验证选项。
以下示例适用于消耗逻辑应用资源,显示了基础连接器资源定义在单一身份验证连接器和多重身份验证连接器之间的差异。
单一身份验证
此示例显示了在消耗逻辑应用工作流中仅支持一种身份验证类型并使用托管标识的连接器操作的基础连接资源定义,其中定义包括以下属性:
消耗逻辑应用的
kind
属性设置为V1
。parameterValueType
属性设置为Alternative
。
{
"type": "Microsoft.Web/connections",
"apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
"name": "[variables('connections_<connector-name>_name')]",
"location": "[parameters('location')]",
"kind": "V1",
"properties": {
"alternativeParameterValues": {},
"api": {
"id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureautomation')]"
},
"authenticatedUser": {},
"connectionState": "Enabled",
"customParameterValues": {},
"displayName": "[variables('connections_<connector-name>_name')]",
"parameterValueSet": {},
"parameterValueType": "Alternative"
}
},
多种身份验证
此示例显示了在消耗逻辑应用工作流中支持多种身份验证类型并使用托管标识的连接器操作的基础连接资源定义,其中定义包括以下属性:
消耗逻辑应用的
kind
属性设置为V1
。parameterValueSet
对象包括一个设置为managedIdentityAuth
的name
属性和一个设置为空对象的values
属性。
{
"type": "Microsoft.Web/connections",
"apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
"name": "[variables('connections_<connector-name>_name')]",
"location": "[parameters('location')]",
"kind": "V1",
"properties": {
"alternativeParameterValues":{},
"api": {
"id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureblob')]"
},
"authenticatedUser": {},
"connectionState": "Enabled",
"customParameterValues": {},
"displayName": "[variables('connections_<connector-name>_name')]",
"parameterValueSet":{
"name": "managedIdentityAuth",
"values": {}
},
"parameterValueType": "Alternative"
}
}
设置对 API 连接身份验证的高级控制
当标准逻辑应用工作流使用由托管连接器创建的 API 连接时,Azure 逻辑应用会使用两个连接与目标资源(如电子邮件帐户、密钥保管库等)通信:
连接 #1 使用内部令牌存储的身份验证进行设置。
连接 #2 使用目标资源的身份验证进行设置。
不过,当消耗逻辑应用工作流使用 API 连接时,无需设置任何配置选项,即可提取连接 #1。 使用标准逻辑应用资源,你可以更好地控制逻辑应用和工作流。 默认情况下,连接 #1 会自动设置为使用系统分配的标识。
如果你的场景需要对 API 连接进行身份验证以实现更精细的控制,你也可以修改连接 #1 的身份验证,将默认的系统分配的标识更改为已添加到逻辑应用的任何用户分配的标识。 此身份验证适用于每个 API 连接,因此,可以将系统分配的标识和用户分配的标识混合应用到同一目标资源的不同连接。
在标准逻辑应用中用于存储每个 API 连接相关信息的 connections.json 文件中,每个连接定义都有两个 authentication
部分,例如:
"keyvault": {
"api": {
"id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
},
"authentication": {
"type": "ManagedServiceIdentity",
},
"connection": {
"id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
},
"connectionProperties": {
"authentication": {
"audience": "https://vault.azure.net",
"type": "ManagedServiceIdentity"
}
},
"connectionRuntimeUrl": "<connection-runtime-URL>"
}
第一个
authentication
部分映射到连接 #1。本部分介绍用于与内部令牌存储进行通信的身份验证。 在过去,对于部署到 Azure 且没有可配置选项的应用,此部分始终设置为
ManagedServiceIdentity
。第二个
authentication
部分映射到连接 #2。本部分介绍用于与目标资源通信的身份验证可能会因你为此连接选择的身份验证类型而异。
为什么需要更改令牌存储的身份验证?
在某些场景下,你可能想要在多个逻辑应用资源之间共享使用同一 API 连接,但不想将每个逻辑应用资源的系统分配的标识添加到目标资源的访问策略中。
在其他方案中,你可能不希望为整个逻辑应用设置系统分配的标识,因此可以将身份验证更改为用户分配的标识,并完全禁用系统分配的标识。
更改令牌存储的身份验证
在 Azure 门户中,打开你的标准逻辑应用资源。
在资源菜单的“工作流”下,选择“连接”。
在“连接”窗格上,选择“JSON 视图”。
在 JSON 编辑器中,找到
managedApiConnections
部分,其中包含逻辑应用资源中所有工作流的 API 连接。查找要添加用户分配的托管标识的连接。
例如,假设工作流具有 Azure Key Vault 连接:
"keyvault": { "api": { "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault" }, "authentication": { "type": "ManagedServiceIdentity" }, "connection": { "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>" }, "connectionProperties": { "authentication": { "audience": "https://vault.azure.net", "type": "ManagedServiceIdentity" } }, "connectionRuntimeUrl": "<connection-runtime-URL>" }
在连接定义中,执行以下步骤:
找到第一部分
authentication
。 如果这一authentication
部分中没有identity
属性,逻辑应用将隐式使用系统分配的标识。根据此步骤中的示例添加
identity
属性。将属性值设置为用户分配的标识的资源 ID。
"keyvault": { "api": { "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault" }, "authentication": { "type": "ManagedServiceIdentity", // Add "identity" property here "identity": "/subscriptions/<Azure-subscription-ID>/resourcegroups/<resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-resource-ID>" }, "connection": { "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>" }, "connectionProperties": { "authentication": { "audience": "https://vault.azure.net", "type": "ManagedServiceIdentity" } }, "connectionRuntimeUrl": "<connection-runtime-URL>" }
在 Azure 门户中,转到目标资源,并根据目标资源的需求授予用户分配的托管标识的访问权限。
例如,对于 Azure Key Vault,将标识添加到密钥保管库的访问策略中。 对于 Azure Blob 存储,将标识的必要角色分配给存储帐户。
禁用托管标识
若要停止使用托管标识进行身份验证,请先删除标识对目标资源的访问权限。 接下来,在逻辑应用资源上关闭系统分配的标识或删除用户分配的标识。
在逻辑应用资源上禁用托管标识时,删除该标识请求访问该标识有权访问的 Azure 资源的功能。
注意
如果禁用系统分配的标识,即使立即再次启用该标识,该逻辑应用工作流中由工作流使用的任何连接在运行时都无法正常工作。 发生此行为的原因是,禁用标识会删除其对象 ID。 在你每次启用标识时,Azure 都会生成具有一个不同且唯一的对象 ID 的标识。 若要解决此问题,你需要重新创建连接,以便它们使用当前系统分配的标识的当前对象 ID。
尽量避免禁用系统分配的标识。 如果要删除标识对 Azure 资源的访问权限,请从目标资源中删除标识的角色分配。 如果删除逻辑应用资源,Azure 将自动从 Microsoft Entra ID 中移除相应的托管标识。
本部分中的步骤包含使用 Azure 门户和 Azure 资源管理器模板(ARM 模板)的情况。 对于 Azure PowerShell、Azure CLI 和 Azure REST API,请参阅以下文档:
工具 | 文档 |
---|---|
Azure PowerShell | 1. 删除角色分配。 2. 删除用户分配的标识。 |
Azure CLI | 1. 删除角色分配。 2. 删除用户分配的标识。 |
Azure REST API | 1. 删除角色分配。 2. 删除用户分配的标识。 |
有关详细信息,请参阅删除 Azure 角色分配。
在 Azure 门户中禁用托管标识
若要删除托管标识的访问权限,请从目标资源中删除标识的角色分配,然后禁用托管标识。
删除角色分配
以下步骤从托管标识中删除对目标资源的访问权限:
在 Azure 门户中,转到你要在其中删除托管标识的访问权限的目标 Azure 资源。
从目标资源的菜单中,选择“访问控制 (IAM)”。 在工具栏下,选择“角色分配”。
在“角色”列表中,选择要删除的托管标识。 在工具栏上,选择“删除”。
提示
如果“删除”选项处于禁用状态,那么你很可能没有权限。 有关可让你管理资源角色的权限的详细信息,请参阅 Microsoft Entra ID 中的管理员角色权限。
在逻辑应用资源上禁用托管标识
在 Azure 门户中,打开你的逻辑应用资源。
在逻辑应用资源菜单上的“设置”下选择“标识”,然后按照标识对应的步骤操作:
选择“系统分配”>“开启”>“保存”。 当 Azure 提示你进行确认时,选择“是”。
选择“用户分配”和托管标识,然后选择“删除”。 当 Azure 提示你进行确认时,选择“是”。
在 ARM 模板中禁用托管标识
如果使用 ARM 模板创建了逻辑应用的托管标识,请将 identity
对象的 type
子属性设置为 None
。
"identity": {
"type": "None"
}