Autenticación del acceso y las conexiones a recursos de Azure con identidades administradas en Azure Logic Apps
Se aplica a: Azure Logic Apps (consumo + estándar)
Si desea evitar proporcionar, almacenar y administrar credenciales, secretos o tokens de Microsoft Entra, puede usar una identidad administrada para autenticar el acceso o las conexiones desde el flujo de trabajo de la aplicación lógica a los recursos protegidos de Microsoft Entra. En Azure Logic Apps, algunas operaciones de conector admiten el uso de una identidad administrada cuando debe autenticar el acceso a recursos protegidos por Microsoft Entra ID. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para obtener más información, consulte ¿Qué son las identidades administradas para recursos de Azure?
Azure Logic Apps admite los siguientes tipos de identidad administrada:
En la siguiente lista se describen algunas diferencias entre estos tipos de identidad administrada:
Un recurso de aplicación lógica solo puede habilitar y usar una única identidad asignada por el sistema.
Un recurso de aplicación lógica puede compartir la misma identidad asignada por el usuario entre un grupo de otros recursos de aplicación lógica.
En esta guía se muestra cómo completar las tareas siguientes:
Habilite y configure la identidad asignada por el sistema para su recurso de aplicación lógica. En esta guía se proporciona un ejemplo que muestra cómo usar la identidad para la autenticación.
Cree y configure una identidad asignada por el usuario. En esta guía se muestra cómo crear esta identidad mediante Azure Portal o una plantilla de Azure Resource Manager (plantilla de ARM) y cómo usar la identidad para la autenticación. Para Azure PowerShell, la CLI de Azure y la API de REST de Azure, consulte la siguiente documentación:
Herramienta Documentación Azure PowerShell Crear una identidad asignada por el usuario Azure CLI Crear una identidad asignada por el usuario API REST de Azure Crear una identidad asignada por el usuario
Requisitos previos
Una cuenta y una suscripción de Azure. Si aún no tiene una, regístrese para obtener una cuenta de Azure gratuita. La identidad administrada y el recurso de Azure de destino al que necesita acceder deben usar la misma suscripción a Azure.
El recurso de Azure de destino al que quiere acceder. En este recurso, debe agregar el rol necesario para que la identidad administrada acceda a ese recurso en nombre de la aplicación lógica o de la conexión. Para agregar un rol a una identidad administrada, necesita permisos de administrador de Microsoft Entra que puedan asignar roles a las identidades del inquilino de Microsoft Entra correspondiente.
El recurso de aplicación lógica y el flujo de trabajo en los que desea usar el desencadenador o las acciones que admiten identidades administradas.
Diferencias de identidad administrada entre aplicaciones lógicas de consumo y estándar
En función del tipo de recurso de aplicación lógica, puede habilitar la identidad asignada por el sistema, la identidad asignada por el usuario o ambas al mismo tiempo:
| Aplicación lógica | Entorno | Compatibilidad con identidad administrada |
|---|---|---|
| Consumo | - Azure Logic Apps multiinquilino - Entorno del servicio de integración (ISE) |
Puede habilitar, ya sea la identidad asignada por el sistema o la identidad asignada por el usuario, pero no ambas en su aplicación lógica. - Puede usar la identidad administrada en el nivel de recurso de la aplicación lógica y en el nivel de conexión. - Si crea y habilita la identidad asignada por el usuario, la aplicación lógica puede tener solo una identidad asignada por el usuario a la vez. |
| Estándar | - Azure Logic Apps de un solo inquilino - App Service Environment v3 (ASEv3) - Logic Apps habilitado para Azure Arc |
- Puede habilitar ambas la identidad asignada por el sistema, que está habilitada de forma predeterminada y la identidad asignada por el usuario al mismo tiempo. También puede agregar varias identidades asignadas por el usuario a la aplicación lógica. Sin embargo, la aplicación lógica solo puede usar una identidad administrada a la vez. - Puede usar la identidad administrada en el nivel de recurso de la aplicación lógica y en el nivel de conexión. |
Para obtener información sobre los límites de identidades administradas en Azure Logic Apps, consulte Límites de identidades administradas para aplicaciones lógicas. Para obtener más información sobre los tipos de recursos y entornos de aplicación lógica estándar y consumo, consulte la siguiente documentación:
Dónde puede usar una identidad administrada
En Azure Logic Apps, solo las operaciones de conectores integrados y gestionados específicos que admiten OAuth con Microsoft Entra ID pueden utilizar una identidad administrada para la autenticación. En las siguientes tablas se ofrece solo una selección a título de ejemplo. Para obtener una lista más completa, consulte la siguiente documentación:
Tipos de autenticación para desencadenadores y acciones que admiten la autenticación
Servicios de Azure que admiten identidades administradas de recursos de Azure
Servicios de Azure que admiten la autenticación de Microsoft Entra
Para un flujo de trabajo de aplicación lógica de consumo, la siguiente tabla enumera conectores de ejemplo que admiten la autenticación de identidad administrada:
| Tipo de conector | Conectores compatibles |
|---|---|
| Integrada | - Azure API Management - Azure App Services - Azure Functions - HTTP - HTTP + Webhook Nota: Las operaciones HTTP pueden autenticar las conexiones a Azure Storage detrás de firewalls de Azure con la identidad asignada por el sistema. Sin embargo, las operaciones HTTP no admiten la identidad asignada por el usuario para autenticar las mismas conexiones. |
| Administrados | - Azure App Service - Azure Automation - Azure Blob Storage - Azure Container Instances - Azure Cosmos DB - Azure Data Explorer - Azure Data Factory - Azure Data Lake - Azure Digital Twins - Azure Event Grid - Azure Event Hubs - Azure IoT Central V2 - Azure Key Vault -Registros de Azure Monitor - Azure Queues - Azure Resource Manager - Azure Service Bus - Azure Sentinel - Azure Table Storage - Azure VM - SQL Server |
Habilitación de la identidad asignada por el sistema en Azure Portal
En un recurso de aplicación lógica consumo, debe habilitar manualmente la identidad asignada por el sistema.
En Azure Portal, abra el recurso de la aplicación lógica de Consumo.
En el menú de la aplicación lógica, en Configuración, seleccione Identidad.
En la página Identidad, en Asignado por el sistema seleccione Activado>Guardar. Cuando Azure le pida confirmación, seleccione Sí.
Nota:
Si recibe un error que le indica que solo puede tener una identidad administrada, el recurso de la aplicación lógica ya está asociado a la identidad asignada por el usuario. Para poder agregar la identidad asignada por el sistema, primero debe quitar la identidad asignada por el usuario del recurso de aplicación lógica.
El recurso de aplicación lógica ahora puede usar la identidad asignada por el sistema. Esta identidad está registrada en Microsoft Entra ID y está representada por un ID de objeto.
Propiedad Valor Descripción Id. de objeto (entidad de seguridad) <identity-resource-ID> Un Identificador único global (GUID) que representa la identidad asignada por el sistema para su aplicación lógica en un inquilino de Microsoft Entra. Ahora siga los pasos de que proporcionan acceso a la identidad asignada por el sistema al recurso más adelante en esta guía.
Habilitación de la identidad asignada por el sistema en una plantilla de ARM
Para automatizar la creación e implementación de aplicaciones lógicas, puede usar una plantilla de ARM. Para habilitar la identidad asignada por el sistema para su recurso de aplicación lógica en la plantilla, agregue el objeto identity y la propiedad secundaria type a la definición del recurso de la aplicación lógica en la plantilla, por ejemplo:
{
"apiVersion": "2016-06-01",
"type": "Microsoft.logic/workflows",
"name": "[variables('logicappName')]",
"location": "[resourceGroup().location]",
"identity": {
"type": "SystemAssigned"
},
"properties": {},
<...>
}
Cuando Azure crea la definición de recursos de la aplicación lógica, el objeto de identidad obtiene las siguientes propiedades:
"identity": {
"type": "SystemAssigned",
"principalId": "<principal-ID>",
"tenantId": "<Entra-tenant-ID>"
}
| Propiedad (JSON) | Value | Descripción |
|---|---|---|
| principalId | <principal-ID> | El Identificador único global (GUID) del objeto principal de servicio para la identidad administrada que representa su aplicación lógica en el inquilino de Microsoft Entra. Este GUID aparece a veces como "Id. de objeto" u objectID. |
| tenantId | <Microsoft-Entra-ID-tenant-ID> | El Identificador único global (GUID) que representa el inquilino de Microsoft Entra al que pertenece la aplicación lógica. Dentro del inquilino de Microsoft Entra, el servicio principal tiene el mismo nombre que la instancia de la aplicación lógica. |
Crear una identidad asignada por el usuario en Azure Portal
Para poder habilitar la identidad asignada por el usuario en un recurso de aplicación lógica de consumo o en un recurso de aplicación lógica estándar, debe crear esa identidad como un recurso de Azure independiente.
En el cuadro de búsqueda de Azure Portal, escriba identidades administradas. En la lista de resultados, seleccione Identidades administradas.
En la barra de herramientas de la página Identidades administradas, seleccione Crear.
Proporcione información sobre la identidad administrada y seleccione Revisar y crear, por ejemplo:
Propiedad Necesario Valor Descripción Suscripción Sí <Azure-subscription-name> Nombre de la suscripción de Azure Grupos de recursos Sí <nombre del grupo de recursos de Azure> El nombre del grupo de recursos de Azure. Cree un nuevo grupo o seleccione uno existente. En este ejemplo se crea un nuevo grupo denominado fabrikam-managed-identities-RG. Región Sí <Azure-region> Región de Azure en la que se va a almacenar la información sobre el recurso. En este ejemplo se usa West US. Nombre Sí <user-assigned-identity-name> Nombre que se va a asignar a la identidad asignada por el usuario. En este ejemplo se usa fabrikam-user-assigned-identity. Una vez que Azure valida la información, crea la identidad administrada. Ahora puede agregar la identidad asignada por el usuario al recurso de aplicación lógica.
Incorporación de una identidad asignada por el usuario a una aplicación lógica mediante Azure Portal
En Azure Portal, abra el recurso de la aplicación lógica de Consumo.
En el menú de la aplicación lógica, en Configuración, seleccione Identidad.
En la página Identidad, seleccione Usuario asignado y luego seleccione Agregar.
En el panel Agregar identidad administrada asignada por el usuario, siga estos pasos:
En la lista Seleccione una suscripción, seleccione la suscripción de Azure.
En la lista que tiene todas las identidades administradas de la suscripción, seleccione la identidad asignada por el usuario que desee. Para filtrar la lista, en el cuadro de búsqueda Identidades administradas asignadas por el usuario, escriba el nombre de la identidad o el grupo de recursos.
Cuando finalice, seleccione Agregar.
Nota
Si recibe un error que le indica que solo puede tener una identidad administrada, la aplicación lógica ya está asociada a la identidad asignada por el sistema. Para poder agregar la identidad asignada por el usuario, primero debe deshabilitar la identidad asignada por el sistema.
La aplicación lógica ahora está asociada a la identidad asignada por el usuario.
Ahora sigue los pasos que dan acceso a la identidad al recurso más adelante en esta guía.
Creación de una identidad asignada por el usuario en una plantilla de ARM
Para automatizar la creación e implementación de aplicaciones lógicas, puede usar una plantilla de ARM. Estas plantillas admiten identidades asignadas por el usuario para la autenticación.
En la sección de recursos de su plantilla, la definición de recursos de su aplicación lógica requiere los siguientes elementos:
Un objeto de identity con la propiedad type establecida a UserAssigned
Un objeto userAssignedIdentities secundario que especifica el recurso asignado al usuario y su nombre
Este ejemplo muestra una definición de recurso y flujo de trabajo de una app de lógica de consumo para una solicitud HTTP PUT con un objeto de identidad no parametrizado. La respuesta a la solicitud PUT y a la operación GET posterior también incluye este objeto identidad:
{
"$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": {}
}
Si su plantilla también incluye la definición de recursos de la identidad administrada, puede parametrizar el objeto de identidad. El siguiente ejemplo muestra cómo el objeto userAssignedIdentities secundario hace referencia a una variable userAssignedIdentityName que se define en la sección de variables de la plantilla. Esta variable hace referencia al identificador de recurso de la identidad asignada por el usuario.
{
"$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": {}
}
]
}
Conceder acceso de identidad a los recursos
Para poder usar la identidad administrada de la aplicación lógica para la autenticación, debe configurar el acceso para la identidad en el recurso de Azure de destino donde desea usar la identidad. La forma en que configuró el acceso varía en función del recurso de destino.
Nota:
Cuando una identidad administrada tiene acceso a un recurso de Azure en la misma suscripción, la identidad solo puede acceder a ese recurso. Sin embargo, en algunos desencadenadores y acciones que admiten identidades administradas, primero debe seleccionar el grupo de recursos de Azure que contiene el recurso de destino. Si la identidad no tiene acceso en el nivel de grupo de recursos, no se muestra ningún recurso de ese grupo, a pesar de tener acceso al recurso de destino.
Para controlar este comportamiento, también debe proporcionar a la identidad acceso al grupo de recursos, no solo al recurso. Del mismo modo, si tiene que seleccionar la suscripción para poder seleccionar el recurso de destino, debe proporcionar a la identidad acceso a la suscripción.
En algunos casos, es posible que necesite la identidad para obtener acceso al recurso asociado. Por ejemplo, supongamos que tiene una identidad administrada para una aplicación lógica que necesita acceso para actualizar la configuración de la aplicación para esa misma aplicación lógica desde un flujo de trabajo. Debe proporcionar a esa identidad acceso a la aplicación lógica asociada.
Por ejemplo, para acceder a una cuenta de Azure Blob Storage o a un almacén de claves de Azure con su identidad administrada, debe configurar el control de acceso basado en rol de Azure (RBAC de Azure) y asignar el rol adecuado para esa identidad a la cuenta de almacenamiento o al almacén de claves, respectivamente.
En los pasos de esta sección se describe cómo asignar acceso basado en roles mediante Azure Portal y plantilla de Azure Resource Manager (Plantilla de ARM). Para Azure PowerShell, la CLI de Azure y la API de REST de Azure, consulte la siguiente documentación:
| Herramienta | Documentación |
|---|---|
| Azure PowerShell | Agregar asignación de roles |
| Azure CLI | Agregar asignación de roles |
| API REST de Azure | Agregar asignación de roles |
Para un almacén de claves de Azure, también tiene la opción de crear una directiva de acceso para la identidad administrada en el almacén de claves y asignar los permisos adecuados para esa identidad en ese almacén de claves. En los pasos incluidos posteriormente en esta sección se describe cómo completar esta tarea mediante Azure Portal. Para las plantillas de Resource Manager, PowerShell y la CLI de Azure, consulte la siguiente documentación:
| Herramienta | Documentación |
|---|---|
| Plantilla de Azure Resource Manager (plantilla de ARM) | Definición de un recurso de directiva de acceso de Key Vault |
| Azure PowerShell | Asignación de una directiva de acceso de Key Vault |
| Azure CLI | Asignación de una directiva de acceso de Key Vault |
Asignación de acceso basado en roles a una identidad administrada mediante Azure Portal
A fin de usar una identidad administrada para la autenticación, algunos recursos de Azure, como las cuentas de almacenamiento de Azure, requieren que asigne esa identidad a un rol que tenga los permisos adecuados en el recurso de destino. Otros recursos de Azure, como los almacenes de claves de Azure, admiten varias opciones, por lo que puede elegir el acceso basado en roles o una directiva de acceso que tenga los permisos adecuados en el recurso de destino para esa identidad.
En Azure Portal, abra el recurso donde desea usar la identidad.
En el menú de recursos, seleccione Control de acceso (IAM)>Agregar>Agregar asignación de roles.
Nota:
Si la opción Adición de la asignación de roles está deshabilitada, no tiene permisos para asignar roles. Para más información, consulte Roles integrados de Microsoft Entra.
Asigne el rol necesario a la identidad administrada. En la pestaña Rol, asigne un rol que dé a la identidad el acceso necesario al recurso actual.
En este ejemplo, asigne el rol denominado Colaborador de datos de Storage Blob, que incluye acceso de escritura para blobs en un contenedor de Azure Storage. Para más información sobre los roles de contenedor de almacenamiento específicos, consulte Roles que pueden acceder a blobs en un contenedor de Azure Storage.
A continuación, elija la identidad administrada donde desea asignar el rol. En Asignar acceso a, seleccione Identidad administrada>Agregar miembros.
En función del tipo de identidad administrada, seleccione o proporcione los valores siguientes:
Tipo Instancia de servicio de Azure Suscripción Miembro Asignada por el sistema Aplicación lógica <Azure-subscription-name> <your-logic-app-name> Asignada por el usuario No aplicable <Azure-subscription-name> <your-user-assigned-identity-name> Para más información sobre cómo asignar roles, consulte Asignación de roles mediante Azure Portal.
Una vez que haya terminado, puede usar la identidad para autenticar el acceso para desencadenadores y acciones que admiten identidades administradas.
Para más información general sobre esta tarea, consulte Asignación de un acceso de identidad administrada a otro recurso mediante Azure RBAC.
Crear una directiva de acceso utilizando Azure Portal
Para usar una identidad administrada para la autenticación, otros recursos de Azure también admiten o requieren que cree una directiva de acceso que tenga los permisos adecuados en el recurso de destino para esa identidad. Otros recursos de Azure, como las cuentas de almacenamiento de Azure, requieren que asigne esa identidad a un rol que tenga los permisos adecuados en el recurso de destino.
En Azure Portal, abra el recurso de destino donde quiere usar la identidad. En este ejemplo se usa un almacén de claves de Azure como recurso de destino.
En el menú de recursos, seleccione Directivas de acceso>Crear, que abre el panel Crear una directiva de acceso.
Nota:
Si el recurso no tiene la opción Directivas de acceso, intente realizar una asignación de roles en su lugar.
En la pestaña Permisos, seleccione los permisos obligatorios que la identidad necesita para acceder al recurso de destino.
Por ejemplo, para utilizar la identidad con la operación Lista de secretos del conector administrado Azure Key Vault, la identidad necesita permisos de lista. Por lo tanto, en la columna Permisos de secretos, seleccione Enumerar.
Cuando esté listo, seleccione Siguiente. En la pestaña Principal, busque y seleccione la identidad administrada, que es una identidad asignada por el usuario en este ejemplo.
Omita el paso Aplicación opcional, seleccione Siguiente y termine de crear la directiva de acceso.
En la siguiente sección se muestra cómo usar una identidad administrada con un desencadenador o una acción para autenticar el acceso. El ejemplo continúa con los pasos de una sección anterior en la que configuró el acceso para una identidad administrada mediante RBAC y una cuenta de almacenamiento de Azure como ejemplo. Sin embargo, los pasos generales para usar una identidad administrada para la autenticación son los mismos.
Autenticación del acceso con una identidad administrada
Después de habilitar la identidad administrada para su recurso de aplicación lógica y dar acceso a esa identidad al recurso o servicio de destino de Azure, puede utilizar esa identidad en desencadenadores y acciones que admitan identidades administradas.
Importante
Antes de que una función de Azure pueda usar la identidad asignada por el sistema, primero habilite la autenticación de Azure Functions.
En los siguientes pasos se muestra cómo usar la identidad administrada con un desencadenador o una acción mediante Azure Portal. Para especificar la identidad administrada en la definición de JSON subyacente de un desencadenador o una acción, consulte Autenticación de identidad administrada.
En Azure Portal, abra el recurso de la aplicación lógica de Consumo.
Si todavía no lo ha hecho, agregue el desencadenador o la acción que admita identidades administradas.
Nota:
No todas las operaciones del conector permiten agregar un tipo de autenticación. Para más información, consulte Tipos de autenticación para desencadenadores y acciones que admiten la autenticación.
Siga estos pasos en el desencadenador o en la acción que agregó:
Operaciones de conector integradas que admiten la autenticación de identidad administrada
Estos pasos continúan usando la acción de HTTP como ejemplo.
En la lista Parámetros avanzados, agregue la propiedad Authentication, si aún no aparece.
Ahora, tanto la propiedad Authentication como la lista Tipo de autenticación aparecen en la acción.
En la lista Tipo de autenticación, seleccione Identidad administrada.
La sección Autenticación ahora muestra las siguientes opciones:
Una lista de identidades administradas en la que puede seleccionar una identidad administrada específica
La propiedad Audience aparece en desencadenadores y acciones específicos para que pueda establecer el identificador de recurso para el recurso o servicio de destino de Azure. De lo contrario, de forma predeterminada, la propiedad Audiencia usa el identificador de recurso
https://management.azure.com/, que es el identificador de recurso para Azure Resource Manager.
En la lista Identidad administrada, seleccione la identidad que desea utilizar, por ejemplo:
Nota:
La opción predeterminada seleccionada es la identidad administrada asignada por el sistema, incluso cuando no tiene habilitada ninguna identidad administrada.
Para usar correctamente una identidad administrada, primero debe habilitar esa identidad en la aplicación lógica. En una aplicación lógica de consumo, puede tener la identidad administrada asignada por el sistema o asignada por el usuario, pero no ambas.
Para obtener más información, consulte Ejemplo: Autenticar activador o acción integrados con una identidad administrada.
Operaciones de conector administrado que admiten la autenticación de identidad administrada
En el panel Crear conexión, en la lista Autenticación, seleccione Identidad administrada, por ejemplo:
En el siguiente panel, para Nombre de conexión, proporcione un nombre que se usará para la conexión.
Para el tipo de autenticación, elija una de las siguientes opciones en función del conector administrado:
Autenticación única: estos conectores solo admiten un tipo de autenticación, que en este caso es la identidad administrada.
En la lista Identidad administrada, seleccione la identidad administrada habilitada actualmente.
Cuando esté listo, seleccione Crear nuevo.
Autenticación múltiple: estos conectores admiten varios tipos de autenticación, pero sólo se puede seleccionar y utilizar un tipo a la vez.
Estos pasos continúan utilizando una acción de Azure Blob Storage como ejemplo.
En la lista Tipo de autenticación, seleccione Identidad administrada de Logic Apps.
Cuando esté listo, seleccione Crear nuevo.
Para obtener más información, consulte Ejemplo: Autenticación del desencadenador o acción del conector administrado con una identidad administrada.
Ejemplo: Autentique una acción o un desencadenador integrado con una identidad administrada
El desencadenador o la acción HTTP integrados pueden usar la identidad asignada por el sistema que se habilita en el recurso de la aplicación lógica. En general, el desencadenador o la acción HTTP usa las siguientes propiedades para especificar el recurso o la entidad a la que desea acceder:
| Propiedad | Obligatorio | Descripción |
|---|---|---|
| Método | Sí | El método HTTP usado por la operación que desea ejecutar |
| URI | Sí | La dirección URL del punto de conexión para acceder a la entidad o recurso de Azure de destino. La sintaxis URI suele incluir el id. del recurso o servicio Azure de destino. |
| Encabezados | No | Los valores de encabezado que necesita o desea incluir en la solicitud saliente, como el tipo de contenido |
| Consultas | No | Cualquier parámetro de consulta que se va a incluir en la solicitud. Por ejemplo, parámetros de consulta para una operación específica o para la versión de API de la operación que quiere ejecutar. |
| Autenticación | Sí | Tipo de autenticación que se utilizará para autenticar el acceso al recurso o servicio de destino de Azure |
Como ejemplo específico, supongamos que desea ejecutar la Operación instantánea de blob en un BLOB de la cuenta Azure Storage en la que previamente configuró el acceso para su identidad. Sin embargo, el conector de Azure Blob Storage no ofrece actualmente esta operación. En su lugar, puede ejecutar esta operación mediante la acción HTTP u otra operación de la API REST de servicios blob.
Importante
Para acceder a cuentas de almacenamiento de Azure situadas detrás de firewalls usando el conector de Azure Blob Storage e identidades administradas, asegúrese de que también configura su cuenta de almacenamiento con la excepción que permite el acceso de los servicios de Microsoft de confianza.
Para ejecutar la operación blob de instantáneas, la acción HTTP especifica estas propiedades:
| Propiedad | Obligatorio | Valor de ejemplo | Descripción |
|---|---|---|---|
| URI | Sí | https://<storage-account-name>/<folder-name>/{name} |
El identificador de recurso de un archivo Azure Blob Storage en el entorno de Azure Global (público), que usa esta sintaxis |
| Método | Sí | PUT |
El método HTTP que utiliza la operación blob de instantáneas |
| Encabezados | Para Azure Storage | x-ms-blob-type = BlockBlob x-ms-version = 2024-05-05 x-ms-date = formatDateTime(utcNow(),'r') |
Los valores de encabezado x-ms-blob-type, x-ms-version y x-ms-date son necesarios para las operaciones de Azure Storage. Importante: En el desencadenador HTTP saliente y en las solicitudes de acción de Azure Storage, el encabezado requiere la propiedad x-ms-version y la versión de la API para la operación que se desea ejecutar. El valor x-ms-date debe ser la fecha actual. En caso contrario, se produce un error de tipo 403 FORBIDDEN en la aplicación lógica. Para obtener la fecha actual en el formato requerido, puede usar la expresión del valor de ejemplo. Para más información, consulte la siguiente documentación: - Encabezados de solicitud - Blob de instantáneas - Control de versiones para servicios de Azure Storage |
| Consultas | Solo para la operación del blob de instantáneas | comp = snapshot |
El nombre y el valor del parámetro de consulta para la operación. |
En el diseñador de flujos de trabajo, agregue cualquier desencadenador que desee y luego agregue la acción HTTP.
En el ejemplo siguiente se muestra una acción HTTP de ejemplo con todos los valores de propiedad descritos anteriormente que se usarán para la operación de blob de instantáneas:
En la acción HTTP, agregue la propiedad Authentication. En la lista Parámetros avanzados, seleccione Autenticación.
La sección Autenticación aparece ahora en la acción HTTP.
Nota:
No todos los desencadenadores y las acciones permiten agregar un tipo de autenticación. Para más información, consulte Tipos de autenticación para desencadenadores y acciones que admiten la autenticación.
En la lista Tipo de autenticación, seleccione Identidad administrada.
En la lista identidades administradas, seleccione entre las opciones disponibles en función de su escenario.
Si configura la identidad asignada por el sistema, seleccione identidad administrada asignada por el sistema.
Si configura la identidad asignada por el usuario, seleccione esa identidad.
Este ejemplo continúa con la Identidad administrada asignada por el sistema.
En algunos desencadenadores y acciones, aparece la propiedad Audience para que pueda establecer el identificador de recurso para el recurso o servicio de Azure de destino.
Por ejemplo, para autenticar el acceso a un recurso de Key Vault en la nube global de Azure, debe establecer la propiedad Audience en exactamente el siguiente id. de recurso:
https://vault.azure.netSi no establece la propiedad Audience, de forma predeterminada, la propiedad Audience utiliza el id. de recurso, que es el id. de recurso
https://management.azure.com/para Azure Resource Manager.Importante
Asegúrese de que el id. del recurso de destino coincide exactamente con el valor que espera Microsoft Entra ID. De lo contrario, puede obtener un error de
400 Bad Requesto un error de401 Unauthorized. Por lo tanto, si el identificador de recurso incluye barras diagonales finales, asegúrese de incluirlas. De lo contrario, no los incluyas.Por ejemplo, el Id. de recurso para todas las cuentas de Azure Blob Storage requiere una barra diagonal final. Sin embargo, el Id. de recurso de una cuenta de almacenamiento específica no requiere una barra diagonal final. Compruebe los ID de recursos de los servicios Azure compatibles con Microsoft Entra ID.
En este ejemplo se establece la propiedad Audiencia en
https://storage.azure.com/, de modo que los tokens de acceso que se usan para la autenticación sean válidos para todas las cuentas de almacenamiento. Sin embargo, también puede especificar una dirección URL de servicio raíz,https://<your-storage-account>.blob.core.windows.net, para una cuenta de almacenamiento específica.
Para obtener más información sobre la autorización de acceso con Microsoft Entra ID para Azure Storage, consulte la siguiente documentación:
Siga creando el flujo de trabajo como desee.
Ejemplo: Autentique una acción o un desencadenador de conector administrado con una identidad administrada
El conector administrado de Azure Resource Manager tiene una acción denominada Leer un recurso, que puede usar la identidad administrada que habilitó para el recurso de aplicación lógica. Este ejemplo muestra cómo utilizar la identidad administrada asignada por el sistema con un conector administrado.
En el diseñador de flujos de trabajo, agregue la acción Azure Resource Manager denominada Leer un recurso.
En el panel Crear conexión, en la lista Autenticación, seleccione Identidad administrada y luego seleccione Iniciar sesión.
Nota:
En otros conectores, la lista Tipo de autenticación muestra Identidad administrada de Logic Apps en su lugar, así que seleccione esta opción.
Proporcione un nombre para la conexión y seleccione la identidad administrada que desea usar.
Si ha habilitado la identidad asignada por el sistema, la lista Identidad administrada selecciona automáticamente Identidad administrada asignada por el sistema. Si ha habilitado una identidad asignada por el usuario en su lugar, la lista selecciona automáticamente la identidad asignada por el usuario.
En este ejemplo, la identidad administrada asignada por el sistema es la única selección disponible.
Nota:
Si la identidad administrada no está habilitada cuando intente crear o cambiar la conexión, o si la identidad administrada se ha eliminado mientras sigue existiendo una conexión habilitada para la identidad administrada, obtendrá un error que le indicará que debe habilitar la identidad y conceder acceso al recurso de destino.
Cuando esté listo, seleccione Crear nuevo.
Una vez que el diseñador crea correctamente la conexión, puede usar la autenticación de identidad administrada para capturar cualquier esquema, contenido o valor dinámico.
Siga creando el flujo de trabajo como desee.
Definición de recursos de la aplicación lógica y conexiones que usan una identidad administrada
Una conexión que habilita y utiliza una identidad administrada es un tipo de conexión especial que sólo funciona con una identidad administrada. En tiempo de ejecución, la conexión usa la identidad administrada que está habilitada en el recurso de aplicación lógica. Azure Logic Apps comprueba si alguna operación de conector administrada en el flujo de trabajo está configurada para utilizar la identidad administrada y si existen todos los permisos necesarios para utilizar la identidad administrada para acceder a los recursos de destino especificados por las operaciones de conector. Si esta comprobación se realiza correctamente, Azure Logic Apps recupera el token de Microsoft Entra asociado a la identidad administrada, utiliza dicha identidad para autenticar el acceso al recurso Azure de destino y realiza las operaciones configuradas en el flujo de trabajo.
En un recurso de aplicación lógica consumo, la configuración de conexión se guarda en el objeto parameters de la definición de recursos, que contiene el objeto $connections que incluye punteros al identificador de recurso de la conexión junto con el identificador de recurso de la identidad administrada cuando se habilita la identidad asignada por el usuario.
Este ejemplo muestra la configuración del objeto parameters cuando la aplicación lógica activa la identidad asignada por el sistema:
"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>"
}
}
}
}
En este ejemplo se muestra la configuración del objeto parameters cuando la aplicación lógica habilita la identidad administrada asignada por el usuario :
"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>"
}
}
}
}
Plantilla de ARM para conexiones de API e identidades administradas
Si utiliza una plantilla de ARM para automatizar la implementación y su flujo de trabajo incluye una conexión API creada por un conector administrado que utiliza una identidad administrada, deberá realizar un paso adicional.
En una plantilla de ARM, la definición del recurso de conector subyacente difiere en función de si tiene un recurso de aplicación lógica de consumo o estándar y de si el conector muestra opciones de autenticación única o autenticación múltiple.
Los siguientes ejemplos se aplican a los recursos de la aplicación lógica de consumo y muestran cómo la definición del recurso del conector subyacente difiere entre un conector de autenticación única y un conector de autenticación múltiple.
Autenticación única
En este ejemplo se muestra la definición de recurso de conexión subyacente para una acción de conector que solo admite un tipo de autenticación y usa una identidad administrada en un flujo de trabajo de aplicación lógica consumo donde la definición incluye los siguientes atributos:
La propiedad
kindse establece enV1para una aplicación lógica de consumo.La propiedad
parameterValueTypese establece enAlternative.
{
"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"
}
},
Autenticación múltiple
En este ejemplo se muestra la definición de recursos de conexión subyacente para una acción del conector que admite varios tipos de autenticación y usa una identidad administrada en un flujo de trabajo de aplicación lógica consumo donde la definición incluye los siguientes atributos:
La propiedad
kindse establece enV1para una aplicación lógica de consumo.El objeto
parameterValueSetincluye una propiedadnameestablecida enmanagedIdentityAuthy una propiedadvaluesestablecida en un objeto vacío.
{
"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"
}
}
Configuración del control avanzado sobre la autenticación de conexiones de API
Cuando el flujo de trabajo de su aplicación lógica estándar utiliza una conexión API, creada por un conector administrado, Azure Logic Apps se comunica con el recurso de destino, como su cuenta de correo electrónico, almacén de claves, etc., mediante dos conexiones:
La conexión número 1 se configura con la autenticación para el almacén de tokens interno.
La conexión número 2 se configura con la autenticación para el recurso de destino.
Sin embargo, cuando un flujo de trabajo de aplicación lógica de consumo usa una conexión de API, la conexión 1 se abstrae de usted sin ninguna opción de configuración. Con el recurso de aplicación lógica estándar, tendrá más control sobre su aplicación lógica y sus flujos de trabajo. De manera predeterminada, la conexión número 1 se configura automáticamente para usar la identidad asignada por el sistema.
Si su escenario requiere un control más preciso sobre la autenticación de las conexiones de API, puede cambiar opcionalmente la autenticación para la conexión #1 de la identidad asignada por el sistema por defecto a cualquier identidad asignada por el usuario que haya agregado a su aplicación lógica. Esta autenticación se aplica a cada conexión de API, por lo que se pueden combinar identidades asignadas por el sistema y asignadas por el usuario en diferentes conexiones al mismo recurso de destino.
En el archivo connections.json de la aplicación lógica Estándar, que almacena información sobre cada conexión de API, cada definición de conexión tiene dos secciones de authentication, por ejemplo:
"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>"
}
La primera sección
authenticationse asigna a la conexión número 1.Esta sección describe la autenticación usada para comunicarse con el almacén de tokens interno. Antes, esta sección siempre se establecía en
ManagedServiceIdentitypara una aplicación que se implementaba en Azure y no tenía opciones configurables.La segunda sección
authenticationse asigna a la conexión número 2.Esta sección describe la autenticación usada para comunicarse con el recurso de destino, que puede variar en función del tipo de autenticación que se seleccione para esa conexión.
¿Por qué cambiar la autenticación para el almacén de tokens?
En algunos escenarios, es posible que quiera compartir y usar la misma conexión de API entre varios recursos de aplicación lógica, pero no agregar la identidad asignada por el sistema para cada recurso de aplicación lógica a la directiva de acceso del recurso de destino.
En otros escenarios, es posible que no quiera que la identidad asignada por el sistema esté configurada completamente en la aplicación lógica, por lo que puede cambiar la autenticación a una identidad asignada por el usuario y deshabilitar completamente la identidad asignada por el sistema.
Cambio de la autenticación para el almacén de tokens
En Azure Portal, abra el recurso Aplicación lógica estándar.
En el menú de recursos, en Flujos de trabajo, seleccione Conexiones.
En el panel de conexiones, seleccione Vista JSON.
En el editor JSON, busque la sección
managedApiConnections, que contiene las conexiones de API de todos los flujos de trabajo del recurso de aplicación lógica.Busque la conexión a la que quiere agregar una identidad administrada asignada por el usuario.
Por ejemplo, supongamos que el flujo de trabajo tiene una conexión de 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>" }En la definición de conexión, realice los pasos siguientes:
Busque la primera sección
authentication. Si no existe ninguna propiedadidentityen esta secciónauthentication, la aplicación lógica usa implícitamente la identidad asignada por el sistema.Agregue una propiedad
identitymediante el ejemplo de este paso.Establezca el valor de propiedad en el identificador de recurso de la identidad asignada por el usuario.
"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>" }En Azure Portal, vaya al recurso de destino y otorgue acceso a la identidad administrada asignada por el usuario en función de las necesidades del recurso de destino.
Por ejemplo, para Azure Key Vault, agregue la identidad a las directivas de acceso del almacén de claves. Para Azure Blob Storage, asigne el rol necesario para la identidad a la cuenta de almacenamiento.
Deshabilitar la identidad administrada
Para dejar de usar la identidad administrada para la autenticación, quite primero el acceso de la identidad al recurso de destino. A continuación, en el recurso de la aplicación lógica, desactive la identidad asignada por el sistema o quite la identidad asignada por el usuario.
Al deshabilitar la identidad administrada en el recurso de la aplicación lógica, se quita la capacidad de esa identidad para solicitar acceso a los recursos de Azure a los que la identidad tenía acceso.
Nota
Si deshabilita la identidad asignada por el sistema, todas las conexiones usadas por los flujos de trabajo en el flujo de trabajo de esa aplicación lógica no funcionarán en tiempo de ejecución, aunque vuelva a habilitarla inmediatamente. Este comportamiento se produce porque deshabilitar la identidad elimina su identificador de objeto. Cada vez que se habilita la identidad, Azure genera la identidad con un identificador de objeto diferente y único. Para resolver este problema, tiene que volver a crear las conexiones para que usen el identificador de objeto actual para la identidad asignada por el sistema actual.
Intente evitar deshabilitar la identidad asignada por el sistema tanto como sea posible. Si desea quitar el acceso de la identidad a los recursos de Azure, quite la asignación de roles de la identidad del recurso de destino. Si elimina su recurso de aplicación lógica, Azure elimina automáticamente la identidad administrada de Microsoft Entra ID.
En los pasos de esta sección se explica cómo usar Azure Portal y la plantilla de Azure Resource Manager (plantilla de ARM). Para Azure PowerShell, la CLI de Azure y la API de REST de Azure, consulte la siguiente documentación:
| Herramienta | Documentación |
|---|---|
| Azure PowerShell | 1. Eliminación de la asignación de roles 2. Eliminación de la identidad asignada por el usuario |
| Azure CLI | 1. Eliminación de la asignación de roles 2. Eliminación de la identidad asignada por el usuario |
| API REST de Azure | 1. Eliminación de la asignación de roles 2. Eliminación de la identidad asignada por el usuario |
Para obtener más información, consulte Eliminación de asignaciones de roles.
Deshabilitar la identidad administrada en Azure Portal
Para quitar el acceso de la identidad administrada, quite la asignación de roles de la identidad del recurso de destino y, a continuación, deshabilite la identidad administrada.
Eliminar asignación de roles
En los pasos siguientes se quita el acceso al recurso de destino de la identidad administrada:
En Azure Portal, vaya al recurso de Azure de destino donde quiere quitar el acceso de la identidad administrada.
En el menú del recurso de destino, seleccione Control de acceso (IAM) . En la barra de herramientas, seleccione Asignación de roles.
En la lista de roles, seleccione las identidades administradas que desea quitar. En la barra de herramientas, seleccione Eliminar.
Sugerencia
Si está deshabilitada la opción Eliminar, lo más probable es que no tenga los permisos correspondientes. Para obtener más información sobre los permisos que le permiten administrar roles para los recursos, consulte permisos de rol de administrador en Microsoft Entra ID.
Deshabilitación de la identidad administrada en el recurso de aplicación lógica
En Azure Portal, abra el recurso de aplicación lógica.
En el menú de recursos de la aplicación lógica, en Configuración, seleccione Identidady siga los pasos de la identidad:
Seleccione Asignado por el sistema>Activado>Guardar. Cuando Azure le pida confirmación, seleccione Sí.
Seleccione Usuario asignado y la identidad administrada y, después, elija Quitar. Cuando Azure le pida confirmación, seleccione Sí.
Deshabilitación de la identidad administrada en una plantilla de ARM
Si creó la identidad administrada de la aplicación lógica mediante una plantilla de ARM, establezca la propiedad secundaria type del objeto identity en None.
"identity": {
"type": "None"
}