Sécuriser un agent n8n avec Identifiant d’assistant Microsoft Entra

Ce guide montre comment déployer n8n sur Azure Container Apps avec l’intégration de Identifiant d’assistant Microsoft Entra. Le déploiement utilise l’interface CLI Azure développeur (azd) pour approvisionner l’infrastructure, créer des objets d’identité Microsoft Entra et configurer automatiquement des flux de travail n8n.

Contrairement à l’authentification avec Microsoft Entra ID modèle sdk Auth (sidecar) utilisé pour les agents personnalisés, l’intégration n8n utilise le nœud de communauté n8n-nodes-entraagentid pour gérer l’acquisition de jetons directement dans les flux de travail n8n. Les workflows déployés illustrent à la fois les flux de jetons autonomes (application uniquement) et « au nom de » (OBO), avec un accès à Microsoft Graph et au serveur Microsoft Graph MCP pour les entreprises, https://mcp.svc.cloud.microsoft/enterprise.

Note

Cet exemple illustre l’utilisation du n8n-nodes-entraagentid nœud de communauté dans n8n. Il n'est pas conseillé de déployer n8n sur Azure en production.

Prerequisites

Avant de commencer, assurez-vous d’avoir :

  • Un abonnement Azure avec un quota pour Azure OpenAI (GPT-4o ou similaire), le serveur flexible PostgreSQL et Azure Container Apps.
  • Rôle de Global Administrator dans votre client Microsoft Entra. Ce rôle est requis, car l’automatisation crée plusieurs objets Microsoft Entra et accorde le consentement administrateur aux autorisations. Utilisez Privileged Identity Management (PIM) pour activer ce rôle au moment voulu.

Azure Cloud Shell (recommandé) est fourni avec tout ce qui est préinstallé : Azure CLI, Azure Developer CLI (azd), PowerShell 7 et Git.

Si vous exécutez localement au lieu de Cloud Shell, installez ces outils avant de continuer :

Authentifiez à la fois les Azure CLI et l’interface CLI Azure développeur afin que les commandes de déploiement puissent créer et gérer des ressources dans votre abonnement :

az login
azd auth login

Cloner et déployer

L’ensemble du déploiement s’exécute via une seule commande azd up qui provisionne Azure infrastructure et configure automatiquement n8n. Procédez comme suit pour déployer n8n :

  1. Ouvrez Azure Cloud Shell et sélectionnez PowerShell.

  2. Clonez le référentiel et démarrez le déploiement :

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

    Dans Azure Cloud Shell, azd auth login affiche un code d’appareil. Ouvrez l’URL affichée et entrez le code pour l’authentification, puis azd up continue automatiquement.

  3. Lorsque vous y êtes invité, fournissez les valeurs suivantes :

    • Nom de l’environnement : Tout nom (par exemple, my-n8n). Utilisé pour isoler ce déploiement.
    • Azure subscription : Sélectionnez l’abonnement à déployer.
    • Azure location : Sélectionnez une région (par exemple, northeurope).
    • Adresse e-mail d’administrateur n8n : Adresse e-mail pour le compte propriétaire n8n.
    • mot de passe d’administrateur n8n : Mot de passe pour le compte de propriétaire n8n (8 caractères minimum, cas mixte, nombre).

  4. Pendant la phase de postprovision, l’automatisation effectue une deuxième connexion. Un code d’appareil s’affiche. Ouvrez l’URL et entrez le code. Cette étape nécessite le rôle Administrateur général ou Administrateur d’application. Le hook post-provisionnement azd up exécute ensuite les opérations suivantes :

    • Crée des objets Identifiant d’assistant Microsoft Entra (Blueprint, Identité de l’agent, Utilisateur de l’agent).
    • Active le Microsoft Graph MCP Server for Enterprise.
    • Attend que n8n devienne prêt.
    • Crée le compte propriétaire.
    • Installe le nœud communautaire @astaykov/n8n-nodes-entraagentid.
    • Génère une clé API pour l’automatisation n8n.
    • Crée les cinq identifiants avec des valeurs réelles.
    • Importe et active les trois workflows de démonstration.

Une fois le déploiement terminé, le script imprime votre URL n8n et un résumé de ce qui a été configuré. L’ID de locataire est détecté automatiquement à partir de votre connexion Azure, donc aucune configuration manuelle n’est nécessaire.

Explorer les ressources déployées

Le déploiement crée des ressources Azure, des objets d’identité Microsoft Entra et des ressources de configuration n8n qui fonctionnent ensemble pour prendre en charge les exemples de flux de travail.

Passer en revue les ressources d’infrastructure Azure

Le déploiement crée les ressources Azure suivantes :

  • Environnement Container Apps : héberge n8n ainsi que la SPA de démonstration.
  • n8n Container App : Exécute l’image officielle n8nio/n8n avec l’entrée HTTPS.
  • Application web statique : SPA de démonstration pour le flux de webhook OBO.
  • Serveur flexible PostgreSQL : Magasin persistant pour les flux de travail, les informations d’identification et l’historique d’exécution (burstable B1ms).
  • Compte de stockage et partage de fichiers : Répertoire persistant /home/node/.n8n . Les nœuds communautaires et la configuration survivent aux redémarrages.
  • Azure OpenAI : déploiement de modèle GPT utilisé par les flux de travail de l’agent IA.
  • Espace de travail Log Analytics : diagnostics et supervision.

Passer en revue les objets d’identité Microsoft Entra

L’automatisation crée ces objets une fois et les réutilise lors des exécutions suivantes :

  • Modèle d’identité d’agent : inscription d’application émettant des jetons pour le compte des identités d’agent via des informations d’identification d’identité fédérée.
  • Principal de service d’identité d’agent : entité de service de l’agent IA. Acquiert des jetons Microsoft Graph et MCP de manière autonome.
  • Compte d’utilisateur de l’agent : Identité d’utilisateur cloud uniquement qui active les flux de jetons délégués (OBO).
  • Inscription d’application SPA (Single Page Application) : application cliente destinée à la démonstration du webhook, préconfigurée avec des URI de redirection et les permissions API du modèle.

Passez en revue les identifiants et les workflows n8n

Le hook postprovision configure automatiquement n8n :

Informations d’identification créées :

  • EntraAgentID - Autonomous : Jeton Microsoft API Graph pour application seule (aucun contexte utilisateur).
  • EntraAgentID - Utilisateur Agent OBO : Jeton délégué au nom de l’Utilisateur Agent.
  • Azure OpenAI : Connexion au modèle GPT déployé pour les flux de travail de l’agent IA.
  • AgentID Auth Manager - Jeton d’accès : Transfert de jetons du Gestionnaire d’authentification vers les nœuds en aval.
  • Bearer issu d’AuthManager : transfert de jeton Bearer pour les appels MCP.

Flux de travail importés :

  • Agent ID Auth Manager – Utilisateur agent avec MCP Enterprise : acquiert un jeton MCP délégué pour l’utilisateur agent et effectue le transfert vers un sous-workflow.
  • HTTP Request with autonomous agent token : Montre un agent autonome appelant Microsoft Graph directement avec un jeton d’application uniquement.
  • Webhook – agent interactif (au nom de) : point d’entrée du webhook recevant un jeton Bearer provenant de la SPA, appelant l’Auth Manager puis répondant via le serveur Graph MCP au nom de l’utilisateur connecté.

Comprendre le flux de jetons

Le déploiement n8n prend en charge deux modèles de flux de jetons :

  • Autonome (application uniquement) : le workflow n8n utilise les informations d’identification du Blueprint d’identité d’agent avec les informations d’identification d’identité fédérée afin d’obtenir un jeton « application uniquement » pour le principal de service d’identité d’agent. Le flux de travail appelle ensuite Microsoft Graph directement avec ce jeton. Aucun contexte utilisateur n’est impliqué.

  • Au nom de (OBO) avec MCP : une SPA exécutée dans le navigateur transmet un jeton Bearer à un webhook n8n. Le webhook appelle le workflow Auth Manager, qui exploite les informations d’identification du Blueprint afin d’obtenir un jeton délégué au nom de l’utilisateur de l’agent. Le Gestionnaire d’authentification transfère le jeton à un sous-flux de travail qui appelle le Microsoft Graph MCP Server for Enterprise, ce qui traduit les appels d’outils MCP en requêtes d’API Microsoft Graph à l’aide du jeton délégué.

Dans les deux modèles, le blueprint d’identité de l’agent agit comme une fabrique de jetons. Le blueprint d’identité de l’agent émet des jetons pour les identités d’agent sans stocker les informations d’identification sur l’agent lui-même. Le nœud de la communauté Auth Manager gère l'acquisition de jetons et la mise en cache AES-256-GCM lors de chaque exécution du flux de travail.

Déployer le test SPA (facultatif)

L’application SPA de test est une application JavaScript statique qui illustre le flux de webhook OBO à partir d’un navigateur.

  1. Déployez-le une fois l’approvisionnement initial terminé :

    azd deploy spa

Comprendre les étendues du serveur MCP

La configuration accorde les étendues déléguées MCP.* suivantes à l’entité de service d’identité de l’agent. Ces étendues reflètent leurs équivalents Microsoft Graph (par exemple, MCP.User.Read.All correspond à User.Read.All) :

  • MCP.User.Read.All : Lire l’ensemble des utilisateurs.
  • MCP.Organization.Read.All : Lire les informations d’organisation du locataire.
  • MCP.Group.Read.All: Lire tous les groupes.
  • MCP.GroupMember.Read.All: Lire les adhésions aux groupes.
  • MCP.Application.Read.All: Lire les inscriptions d’applications et les principaux de service.
  • MCP.AuditLog.Read.All: Lire les journaux de connexion et d’audit.
  • MCP.Reports.Read.All : lire les rapports d’utilisation de Microsoft 365.
  • MCP.Policy.Read.All: Lire les stratégies d’accès conditionnel.
  • MCP.Domain.Read.All: Consulter les domaines vérifiés.
  • MCP.Device.Read.All : Lire les appareils enregistrés dans Microsoft Entra.

Pour ajouter d’autres étendues, modifiez le $MCP_SCOPES tableau dans scripts/Setup-EntraAgentId.ps1 et réexécutez azd provision.

Note

Le serveur MCP prend uniquement en charge les flux d’autorisations délégués. Utilisez les informations d'identification autonomes pour les appels exclusivement pour l'application de Microsoft Graph.

Réexécuter et mettre à jour le déploiement

Le déploiement est entièrement idempotent :

  • Bicep ignore les ressources Azure qui sont déjà présentes.
  • L’environnement azd enregistre Microsoft Entra ID d’objet (Blueprint, Agent Identity, Agent User, Blueprint Secret) après la première exécution et les réutilise lors des exécutions suivantes.
  • La configuration n8n (informations d’identification, workflows) est appliquée à chaque exécution, ce qui permet de réparer un état rompu.

Pour réexécuter uniquement les scripts postprovisionnement sans modifier l’infrastructure, réexécutez l’approvisionnement. Les modèles Bicep détectent aucune modification de l’infrastructure et exécutent uniquement les hooks de déploiement :

azd provision   # Bicep detects no changes, runs hooks only

Exécuter les scripts manuellement (facultatif)

Vous pouvez exécuter les scripts de configuration indépendamment si nécessaire :

  • Complète de bout en bout (Microsoft Entra et n8n) : 

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

  • Configuration n8n uniquement (ignorer l’installation d’Entra) :

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

  • Configuration d’Entra uniquement :

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

Nettoyer les ressources

Supprimez toutes les ressources Azure que le déploiement a créées et videz tout état de déploiement conservé :

azd down --purge

Note

La commande azd down supprime Azure ressources, mais ne supprime pas d'objets Microsoft Entra tels que des blueprints, des identités d'agent ou des comptes d'utilisateur d'agent. Supprimez ces objets manuellement dans le centre d’administration Microsoft Entra s'ils ne sont plus nécessaires.

Contenu connexe

  • Last updated on