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)
Cuando se usa una identidad administrada para autenticar el acceso o las conexiones a recursos protegidos de Microsoft Entra desde el flujo de trabajo de la aplicación lógica, no es necesario proporcionar credenciales, secretos ni tokens de Microsoft Entra. En Azure Logic Apps, algunas operaciones del conector admiten el uso de una identidad administrada cuando tiene que autenticar el acceso a los recursos protegidos por el identificador de Entra de Microsoft. Azure administra esta identidad y ayuda a proteger la información de autenticación, ya que no tiene que administrar esta información confidencial. Para más información, consulte ¿Qué es Managed Identities for Azure Resources?
Azure Logic Apps admite la identidad administrada asignada por el sistema y la identidad administrada asignada por el usuario. En la lista siguiente 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 administrada asignada por el sistema para el 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 una identidad asignada por el usuario mediante Azure Portal y la 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 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 |
Consumo frente a aplicaciones lógicas 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) |
- La aplicación lógica puede habilitar o bien el tipo de identidad asignada por el sistema o el tipo de identidad asignada por el usuario. - Puede usar la identidad administrada en el nivel del recurso de aplicación lógica y el nivel de conexión. - Si habilita la identidad asignada por el usuario, la aplicación lógica solo puede tener 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 la identidad asignada por el sistema, que está habilitada de forma predeterminada y la identidad asignada por el usuario al mismo tiempo. - Puede usar la identidad administrada en el nivel del recurso de aplicación lógica y el nivel de conexión. - Si habilita la identidad asignada por el usuario, el recurso de la aplicación lógica puede tener varias identidades asignadas por el usuario al mismo tiempo. |
Para obtener información sobre los límites de identidad administrada 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 conector integradas y administradas específicas que admiten OAuth con el identificador de Entra de Microsoft pueden usar una identidad administrada para la autenticación. En las tablas siguientes solo se proporciona una selección de ejemplo. Para obtener una lista más completa, consulte Tipos de autenticación para desencadenadores y acciones que admiten la autenticación y los servicios de Azure que admiten la autenticación de Microsoft Entra con identidades administradas.
Para un flujo de trabajo de aplicación lógica de consumo, en la tabla siguiente se enumeran los conectores 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, no admiten la identidad administrada 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 Event Grid - Azure Event Hubs - Azure IoT Central V2 - Azure IoT Central V3 - Azure Key Vault - Azure Log Analytics - Azure Queues - Azure Resource Manager - Azure Service Bus - Azure Sentinel - Azure Table Storage - Azure VM - HTTP con Microsoft Entra ID - SQL Server |
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, agregará el rol necesario para que la identidad administrada acceda a ese recurso en nombre de la aplicación lógica o la conexión. Para agregar un rol a una identidad administrada, se necesitan permisos de administrador de Microsoft Entra que puedan asignar roles a identidades en el inquilino correspondiente de Microsoft Entra.
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.
Habilitación de la identidad asignada por el sistema en Azure Portal
En Azure Portal, abra el recurso de aplicación lógica.
En el menú de la aplicación lógica, en Configuración, seleccione Identidad.
En la página Identidad, en Sistema asignado, seleccione Al>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 que proporcionan a esa identidad acceso 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 administrada asignada por el sistema para el recurso de la aplicación lógica en la plantilla, agregue el objeto identity y la propiedad secundaria type a la definición de recursos 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 recurso de la aplicación lógica, el objeto identity obtiene estas otras propiedades:
"identity": {
"type": "SystemAssigned",
"principalId": "<principal-ID>",
"tenantId": "<Azure-AD-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" o objectID. |
tenantId |
<Azure-AD-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 el recurso de aplicación lógica consumo o en el 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 y seleccione Identidades administradas.
En 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 Grupo 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 aplicación lógica.
En el menú de la aplicación lógica, en Configuración, seleccione Identidad.
En la página Identidad, seleccione Agregar asignado por> el usuario.
En el panel Agregar identidad administrada asignada por el usuario, siga estos pasos:
En la lista 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 administrada asignada por el usuario.
Ahora siga los pasos que proporcionan a esa identidad acceso 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 resources de la plantilla, la definición de recursos de la aplicación lógica requiere estos elementos:
Un objeto
identitycon la propiedadtypeestablecida enUserAssigned.Objeto secundario
userAssignedIdentitiesque especifica el nombre y el recurso asignados por el usuario.
En este ejemplo se muestra un recurso de aplicación lógica de consumo y una definición de flujo de trabajo para una solicitud HTTP PUT con un objeto no parametrizado identity . La respuesta a la solicitud PUT y a la operación GET posterior también incluye este identity objeto:
{
"$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 la plantilla también incluye la definición de recursos de la identidad administrada, puede parametrizar el objeto identity. En el ejemplo siguiente se muestra cómo el objeto secundario userAssignedIdentities hace referencia a una userAssignedIdentityName variable que se define en la sección de la variables 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
A fin de 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 en el que quiere usarla. La forma de configurar el acceso varía en función del recurso al que quiere que acceda la identidad.
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 con su identidad administrada, debe configurar el acceso mediante 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. En los pasos de esta sección se describe cómo completar esta tarea mediante Azure Portal y una plantilla de Azure Resource Manager (plantilla de ARM). Para Azure PowerShell, la CLI de Azure y la API 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 |
Sin embargo, para acceder a un almacén de claves de Azure con su identidad administrada, debe crear una directiva de acceso para esa identidad 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 del acceso basado en rol de la identidad administrada en 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, requieren que cree 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 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.
Ahora, 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 la asignación de roles, consulte Asignación de roles mediante Azure Portal.
Cuando termine, puede usar la identidad a fin de 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.
Creación de una directiva de acceso en Azure Portal
A fin de usar una identidad administrada para la autenticación, algunos recursos de Azure, como los almacenes de claves de Azure, 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ú del recurso, seleccione Directivas de acceso>Crear, y se abrirá 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 usar la identidad con la operación Enumerar secretos del conector administrado de Azure Key Vault, la identidad necesita permisos de enumeración. 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 sección siguiente se describe el uso de una identidad administrada para autenticar el acceso para un desencadenador o una acción. El ejemplo continúa con los pasos de una sección anterior en la que se configuró el acceso para una identidad administrada mediante RBAC y no usa Azure Key Vault 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 el recurso de aplicación lógica y conceder a esa identidad acceso al recurso o a la entidad de destino, puede usar esa identidad en desencadenadores y acciones que admiten 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 estos pasos se muestra cómo usar la identidad administrada con un desencadenador o una acción a través del 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 aplicación lógica.
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
En la lista Agregar nuevo parámetro, agregue la propiedad Autenticación si todavía no aparece.
En la lista Tipo de autenticación, seleccione Identidad administrada.
Para obtener más información, vea Ejemplo: Autenticación de un desencadenador o una acción integrados con una identidad administrada.
Operaciones de conector administrado que admiten la autenticación de identidad administrada
En la página de selección de inquilinos, seleccione Conexión con identidad administrada, por ejemplo:
En la página siguiente, en el nombre de la conexión, escriba un nombre 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. En la lista Identidad administrada, seleccione la identidad administrada habilitada actualmente, si aún no está seleccionada, y, a continuación, elija Crear, por ejemplo:
Autenticación múltiple: estos conectores muestran varios tipos de autenticación, pero todavía puede seleccionar un solo tipo. En la lista Tipo de autenticación, seleccione Identidad administrada de aplicaciones lógicas>Crear, por ejemplo:
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 del URI normalmente incluye el Id. de recurso para el recurso o servicio de Azure. |
| 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í | El tipo de autenticación que se va a usar para autenticar el acceso al recurso o entidad de destino |
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 |
|---|---|---|---|
| Método | Sí | PUT |
El método HTTP que utiliza la operación blob de instantáneas |
| 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 |
| Encabezados | Para Azure Storage | x-ms-blob-type = BlockBlob
|
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 Para obtener más información, consulte la siguiente documentación: - Encabezados de solicitud - Blob de instantáneas |
| 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 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:
Después de agregar la acción HTTP, agregue la propiedad Autenticación a la acción HTTP. En la lista Agregar nuevo parámetro, seleccione Autenticación.
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 aún no está seleccionada.
Si configura una identidad asignada por el sistema, seleccione esa identidad si aún no lo está.
Este ejemplo continúa con la Identidad administrada asignada por el sistema.
En algunos desencadenadores y acciones, la propiedad Audiencia también aparece para que pueda establecer el identificador de recurso de destino. Establezca la propiedad Audiencia en el identificador de recurso para el recurso o servicio de destino. 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.Por ejemplo, si desea autenticar el acceso a un recurso de Key Vault en la nube global de Azure, debe establecer la propiedad Audiencia en el siguiente identificador de recurso exactamente:
https://vault.azure.net. Tenga en cuenta que este identificador de recurso específico no tiene barras diagonales finales. De hecho, incluir una barra diagonal final podría producir un error400 Bad Requesto un error401 Unauthorized.Importante
Asegúrese de que el ID del recurso de destino coincide exactamente con el valor que espera Microsoft Entra ID, incluidas las barras finales necesarias. 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 cómo autorizar el 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. En este ejemplo se muestra cómo usar la identidad administrada asignada por el sistema.
Luego de agregar la acción a su flujo de trabajo y seleccionar su inquilino Microsoft Entra, seleccione Conectar con identidad administrada.
En la página del nombre de la conexión, dé un nombre a la conexión y seleccione la identidad administrada que desea usar.
La acción de Azure Resource Manager es una acción de autenticación única, por lo que el cuadro información de conexión muestra una lista identidad administrada que selecciona automáticamente la identidad administrada que está habilitada actualmente en el recurso de aplicación lógica. Si ha habilitado una identidad administrada asignada por el sistema, la lista Identidad administrada selecciona Identidad administrada asignada por el sistema. Si en su lugar ha habilitado una identidad administrada asignada por el usuario, la lista selecciona esa identidad en su lugar.
Si usa un desencadenador o una acción de autenticación múltiple, como Azure Blob Storage, el cuadro de información de conexión muestra una lista de tipos de autenticación que incluye la opción Identidad administrada de Logic Apps entre otros tipos de autenticación.
En este ejemplo, la identidad administrada asignada por el sistema es la única selección disponible.
Nota:
Si la identidad administrada no está habilitada al intentar crear la conexión, se ha cambiado o se quitó mientras aún existe una conexión habilitada para identidad administrada, aparece un error que indica que debe habilitar la identidad y conceder acceso al recurso de destino.
Cuando esté listo, seleccione Crear.
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 permite y usa una identidad administrada es un tipo de conexión especial que solo 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. En tiempo de ejecución, el servicio Azure Logic Apps comprueba si las acciones o los desencadenadores de conector administrado del flujo de trabajo de la aplicación lógica están configurados para usar la identidad administrada y si todos los permisos necesarios están configurados para usar la identidad administrada a fin de acceder a los recursos de destino especificados por el desencadenador y las acciones. Si se realiza correctamente, Azure Logic Apps recupera el token de Microsoft Entra asociado a la identidad administrada y utiliza dicha identidad para autenticar el acceso al recurso de destino y realizar la operación configurada en el activador y las acciones.
En un recurso de aplicación lógica consumo, la configuración de conexión se guarda en el objeto de la definición de recursos de parameters la aplicación lógica, que contiene el $connections objeto que incluye punteros al identificador de recurso de la conexión junto con el identificador de recurso de la identidad, si la identidad asignada por el usuario está habilitada.
En este ejemplo se muestra el aspecto de la configuración cuando la aplicación lógica habilita la identidad administrada asignada por el sistema:
"parameters": {
"$connections": {
"value": {
"<action-name>": {
"connectionId": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/{connection-name}",
"connectionName": "{connection-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 el aspecto de la configuración cuando la aplicación lógica habilita una identidad administrada asignada por el usuario:
"parameters": {
"$connections": {
"value": {
"<action-name>": {
"connectionId": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/{connection-name}",
"connectionName": "{connection-name}",
"connectionProperties": {
"authentication": {
"type": "ManagedServiceIdentity",
"identity": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resourceGroupName}/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 usa una plantilla de ARM para automatizar la implementación y el flujo de trabajo incluye una conexión de API que se crea mediante un conector administrado, como por ejemplo Office 365 Outlook o Azure Key Vault, que usa una identidad administrada, tiene que realizar un paso adicional.
En una plantilla de ARM, la definición de recurso del conector subyacente difiere en función de si tiene una aplicación lógica estándar o de consumo y de si el conector muestra opciones de autenticación única o de autenticación múltiple.
Los ejemplos siguientes se aplican a los recursos de la aplicación lógica de consumo y muestran cómo la definición de recursos del conector subyacente difiere entre un conector de autenticación única, como Azure Automation y un conector de autenticación múltiple, como Azure Blob Storage.
Autenticación única
Este ejemplo muestra la definición de recurso de conexión subyacente para una acción de Azure Automation en una aplicación lógica de consumo que usa una identidad administrada en la que la definición incluye los 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_azureautomation_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_azureautomation_name')]",
"parameterValueSet": {},
"parameterValueType": "Alternative"
}
},
Autenticación múltiple
Este ejemplo muestra la definición de recurso de conexión subyacente para una acción de Azure Blob Storage en una aplicación lógica de consumo que usa una identidad administrada en la que la definición incluye los atributos siguientes:
- 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_azureblob_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_azureblob_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 usa una conexión de API que se crea mediante un conector administrado, como Office 365 Outlook o Azure Key Vault, entre otros, el servicio Azure Logic Apps se comunica con el recurso de destino, como por ejemplo la cuenta de correo electrónico o el almacén de claves, 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.
En un recurso de aplicación lógica de consumo, la conexión número 1 se extrae del usuario sin ninguna opción de configuración. En el tipo de recurso de aplicación lógica estándar, el usuario tiene más control sobre la aplicación lógica. De manera predeterminada, la conexión número 1 se configura automáticamente para usar la identidad asignada por el sistema.
Sin embargo, si el escenario requiere un mayor control sobre la autenticación de conexiones de API, opcionalmente se puede cambiar la autenticación de la conexión número 1 de la identidad predeterminada asignada por el sistema a cualquier identidad asignada por el usuario que se haya agregado a la 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, la definición de cada conexión tiene dos secciones authentication, por ejemplo:
"keyvault": {
"api": {
"id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/keyvault"
},
"authentication": {
"type": "ManagedServiceIdentity",
},
"connection": {
"id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-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 enManagedServiceIdentitypara 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 en varias aplicaciones lógicas, pero no agregar la identidad asignada por el sistema para cada 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/{region}/managedApis/keyvault" }, "authentication": { "type": "ManagedServiceIdentity" }, "connection": { "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-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/{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/<connection-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 al deshabilitar la identidad se elimina el 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 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 |
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 recursos, consulte Administración permisos de rolistrator 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 navegación de la aplicación lógica, en Configuración, seleccione Identidad y, a continuación, siga los pasos adecuados para su 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"
}