Proteja un agente n8n con Agente de Microsoft Entra ID

En esta guía se muestra cómo implementar n8n en Azure Container Apps con la integración de Agente de Microsoft Entra ID. La implementación usa la CLI de Azure Developer (azd) para aprovisionar la infraestructura, crear Microsoft Entra objetos de identidad y configurar flujos de trabajo n8n automáticamente.

A diferencia del patrón Authentication with Microsoft Entra ID Auth SDK (sidecar) usado para agentes personalizados, la integración n8n usa el nodo de la comunidad n8n-nodes-entraagentid para administrar la adquisición de tokens directamente dentro de los flujos de trabajo n8n. Los flujos de trabajo implementados muestran flujos de tokens tanto autónomos (solo de aplicación) como en nombre de (OBO), con acceso a Microsoft Graph y al servidor MCP de Microsoft Graph para empresas, https://mcp.svc.cloud.microsoft/enterprise.

Nota

En este ejemplo se muestra el uso del nodo de la comunidad n8n-nodes-entraagentid en n8n. No es una guía para implementar n8n en Azure en producción.

Prerrequisitos

Antes de comenzar, asegúrese de que tiene:

  • Una suscripción de Azure con cuota para Azure OpenAI (GPT-4o o similar), servidor flexible de PostgreSQL y Azure Container Apps.
  • Rol de Administrador global en su inquilino de Microsoft Entra. Este rol es necesario porque la automatización crea varios objetos Microsoft Entra y concede el consentimiento del administrador a los permisos. Use Privileged Identity Management (PIM) para activar este rol justo a tiempo.

Azure Cloud Shell (recomendado) incluye todo lo preinstalado: CLI de Azure, cli de Azure developer (azd), PowerShell 7 y Git.

Si se ejecuta localmente en lugar de Cloud Shell, instale estas herramientas antes de continuar:

Autentíquese tanto el CLI de Azure como la CLI de Azure Developer para que los comandos de implementación puedan crear y administrar recursos en la suscripción:

az login
azd auth login

Clonación e implementación

Toda la implementación se ejecuta a través de un único comando azd up que aprovisiona Azure infraestructura y configura n8n automáticamente. Siga estos pasos para implementar n8n:

  1. Abra Azure Cloud Shell y seleccione PowerShell.

  2. Clone el repositorio e inicie la implementación:

    git clone https://github.com/astaykov/n8n-aca.git && cd n8n-aca && azd auth login && azd up

    En Azure Cloud Shell, azd auth login muestra un código de dispositivo. Abra la dirección URL que se muestra y escriba el código para autenticarse y, a continuación azd up , continúe automáticamente.

  3. Cuando se le solicite, proporcione los siguientes valores:

    • Nombre del entorno: Cualquier nombre (por ejemplo, my-n8n). Se utiliza para aislar esta implementación.
    • Azure subscription: Seleccione la suscripción en la que se va a implementar.
    • Azure location: Seleccione una región (por ejemplo, northeurope).
    • Correo electrónico de administrador n8n: Correo electrónico de la cuenta de propietario n8n.
    • n8n contraseña de administrador: Contraseña de la cuenta de propietario n8n (mínimo 8 caracteres, mayúsculas y minúsculas mixtas, número).

  4. Durante la fase posterior al aprovisionamiento, la automatización efectúa un segundo inicio de sesión. Se muestra un código de dispositivo. Abra la dirección URL y escriba el código. Este paso requiere el rol Administrador global o Administrador de aplicaciones. El gancho de posaprovisionamiento de azd up y después:

    • Crea objetos Agente de Microsoft Entra ID (Blueprint, Agent Identity, Agent User).
    • Habilita el Microsoft Graph servidor MCP para empresas.
    • Espera a que n8n esté listo.
    • Crea la cuenta de propietario.
    • Instala el @astaykov/n8n-nodes-entraagentid nodo de la comunidad.
    • Genera una clave de API para la automatización n8n.
    • Crea las cinco credenciales con valores reales.
    • Importa y activa los tres flujos de trabajo de demostración.

Una vez completada la implementación, el script imprime la dirección URL de n8n y un resumen de lo que se configuró. El identificador de inquilino se detecta automáticamente desde el inicio de sesión de Azure, por lo que no se necesita ninguna configuración manual.

Exploración de los recursos implementados

La implementación crea recursos de Azure, objetos de identidad de Microsoft Entra y recursos de configuración de n8n que funcionan conjuntamente para permitir los flujos de trabajo de ejemplo.

Revisión de los recursos de infraestructura de Azure

La implementación crea los siguientes recursos de Azure:

  • Entorno de aplicaciones en contenedor: Aloja n8n y la SPA de prueba.
  • n8n Container App: Ejecuta la imagen oficial n8nio/n8n con entrada HTTPS.
  • Static Web App: SPA de prueba para el flujo de webhook de OBO.
  • Servidor flexible de PostgreSQL: Almacenamiento persistente para flujos de trabajo, credenciales e historial de ejecución (Burstable B1ms).
  • Cuenta de almacenamiento y compartición de archivos: Directorio persistente /home/node/.n8n . Los nodos de la comunidad y la configuración sobreviven a los reinicios.
  • Azure OpenAI: implementación del modelo GPT usada por los flujos de trabajo del agente de IA.
  • Log Analytics Workspace: Diagnóstico y supervisión.

Revisión de los objetos de identidad de Microsoft Entra

La automatización crea estos objetos una vez y los reutiliza en ejecuciones posteriores:

  • Plantilla de identidad de agente: Registro de aplicación que emite tokens en nombre de las identidades de agente a través de credenciales de identidad federada.
  • Entidad de servicio de identidad de agente: La entidad de servicio del agente de IA. Adquiere tokens de Microsoft Graph y MCP de forma autónoma.
  • Cuenta de usuario del agente: Una identidad de usuario solo en la nube que habilita flujos de token delegados (OBO).
  • Registro de la aplicación de página única (SPA): Aplicación cliente para la demostración del webhook, preconfigurada con URI de redireccionamiento y permisos de la API del modelo.

Revise las credenciales y los flujos de trabajo de n8n.

El gancho postprovision configura automáticamente n8n:

Credenciales creadas:

  • EntraAgentID - Autónomo: token de Microsoft Graph API solo para aplicaciones (sin contexto de usuario).
  • EntraAgentID - Usuario del agente OBO: Token delegado en nombre del usuario del agente.
  • Azure OpenAI: Conexión al modelo GPT implementado para flujos de trabajo del agente de IA.
  • Administrador de autenticación de AgentID - Token de acceso: Reenvío de tokens desde el Administrador de autenticación a los nodos descendentes.
  • Portador de AuthManager: Reenvío de token de portador para llamadas MCP.

Flujos de trabajo importados:

  • Administrador de Autenticación de ID de Agente - Usuario Agente con MCP Enterprise: Adquiere un token de MCP delegado para el Usuario Agente y lo reenvía a un subflujo de trabajo.
  • HTTP Request with autonomous agent token: Muestra un agente autónomo que llama Microsoft Graph directamente con un token de solo aplicación.
  • Webhook - agente interactivo (on-behalf-of): Punto de entrada del webhook que recibe un token portador de la SPA, llama a Auth Manager y responde a través del servidor Graph MCP en nombre del usuario autenticado.

Descripción del flujo de tokens

La implementación de n8n admite dos patrones de flujo de tokens:

  • Autónomo (solo aplicación): El flujo de trabajo de n8n utiliza las credenciales del Blueprint de identidad del agente con credenciales de identidad federada para adquirir un token de solo aplicación para la entidad de servicio de identidad del agente. A continuación, el flujo de trabajo llama a Microsoft Graph directamente con este token. No hay ningún contexto de usuario implicado.

  • En nombre de (OBO) con MCP: Una SPA basada en navegador envía un token de portador a un webhook de n8n. El webhook llama al flujo de trabajo de Auth Manager, que utiliza las credenciales del Blueprint para adquirir un token delegado en nombre del usuario agente. El Administrador de autenticación reenvía el token a un subproceso que llama al Microsoft Graph MCP Server for Enterprise, que traduce las llamadas de la herramienta MCP a solicitudes de API Microsoft Graph mediante el token delegado.

En ambos patrones, Agent Identity Blueprint actúa como factoría de tokens. Agent Identity Blueprint emite tokens para identidades de agentes sin almacenar credenciales en el propio agente. El nodo de la comunidad de Auth Manager controla la adquisición de tokens y el almacenamiento en caché de AES-256-GCM dentro de cada ejecución de flujo de trabajo.

Implementación de la SPA de prueba (opcional)

La SPA de prueba es una aplicación de JavaScript estática que muestra el flujo de webhook de OBO desde un explorador.

  1. Impleméntelo una vez completado el aprovisionamiento inicial:

    azd deploy spa

Descripción de los ámbitos del servidor MCP

La configuración concede los siguientes ámbitos delegados MCP.* a la entidad de servicio de identidad del agente. Estos ámbitos reflejan sus homólogos de Microsoft Graph (por ejemplo, MCP.User.Read.All corresponde a User.Read.All):

  • MCP.User.Read.All: Leer todos los usuarios.
  • MCP.Organization.Read.All: Lea la información de la organización del cliente.
  • MCP.Group.Read.All: Leer todos los grupos.
  • MCP.GroupMember.Read.All: Leer las membresías de los grupos.
  • MCP.Application.Read.All: Leer registros de aplicaciones y entidades de servicio.
  • MCP.AuditLog.Read.All: Leer registros de inicio de sesión y de auditoría.
  • MCP.Reports.Read.All: leer informes de uso de Microsoft 365.
  • MCP.Policy.Read.All: lee las directivas de acceso condicional.
  • MCP.Domain.Read.All: Consultar dominios verificados.
  • MCP.Device.Read.All: Leer dispositivos registrados en Microsoft Entra.

Para agregar más ámbitos, edite la $MCP_SCOPES matriz en scripts/Setup-EntraAgentId.ps1 y vuelva a ejecutar azd provision.

Nota

El servidor MCP solo admite flujos de permisos delegados. Utilizar las credenciales autónomas para llamadas a Microsoft Graph exclusivas de aplicaciones.

Volver a ejecutar y actualizar la implementación

La implementación es totalmente idempotente:

  • Bicep omite recursos de Azure que ya existen.
  • El entorno azd guarda las identificaciones de objeto de Microsoft Entra (Blueprint, Agent Identity, Agent User, Blueprint secret) después de la primera ejecución y las reutiliza en ejecuciones posteriores.
  • La configuración n8n (credenciales, flujos de trabajo) se aplica de nuevo cada ejecución, lo que permite reparar un estado roto.

Para volver a ejecutar solo los scripts posteriores al aprovisionamiento sin modificar la infraestructura, vuelva a ejecutar el aprovisionamiento. Las plantillas de Bicep no detectan ningún cambio de infraestructura y solo ejecutan los enlaces de implementación:

azd provision   # Bicep detects no changes, runs hooks only

Ejecutar los scripts manualmente (opcional)

Puede ejecutar los scripts de configuración de forma independiente si es necesario:

  • Integración completa de principio a fin (Microsoft Entra y n8n):

    .\scripts\Run-All.ps1 `
    -TenantId  "<your-tenant-id>" `
    -N8nUrl    "https://ca-n8n-<token>.<region>.azurecontainerapps.io"

  • Solo configuración de n8n (omitir la configuración de Entra):

    .\scripts\Configure-N8n.ps1 `
    -N8nUrl          "https://ca-n8n-<token>.<region>.azurecontainerapps.io" `
    -OwnerEmail      "admin@contoso.com" `
    -OwnerPassword   "MyStr0ngPassword!"

  • Solo configuración de Entra:

    .\scripts\Setup-EntraAgentId.ps1 `
    -TenantId  "<your-tenant-id>" `
    -N8nUrl    "https://ca-n8n-<token>.<region>.azurecontainerapps.io"

Limpieza de recursos

Elimine todos los recursos de Azure que creó la implementación y purgue cualquier estado de implementación conservado:

azd down --purge

Nota

El comando azd down quita recursos de Azure, pero no elimina objetos de Microsoft Entra como planos, identidades de agente o cuentas de usuario del agente. Quite estos objetos manualmente en el Centro de administración Microsoft Entra si ya no son necesarios.

Contenido relacionado

  • Last updated on