Intégrer des agents tiers à Identifiant d’assistant Microsoft Entra

Identifiant d’assistant Microsoft Entra permet aux agents d’IA de plateformes tierces d’authentifier et d’accéder en toute sécurité à vos API sans gérer directement les informations d’identification. Cet article traite de deux modèles d’intégration : le sdk d’Microsoft Entra ID Auth (sidecar) et la fédération pour les plateformes telles qu’Amazon Web Service (AWS) Bedrock et n8n.

Prerequisites

Avant de commencer, vérifiez que vous disposez des éléments suivants :

  • Tenant Microsoft Entra sur lequel les fonctionnalités d’identité d’agent sont activées.
  • abonnement Azure requis pour certaines options de déploiement.
  • Docker et Docker Compose pour le modèle de sidecar.
  • Informations d’identification ou configuration de fédération, selon le modèle que vous choisissez.
  • PowerShell 7.5 ou version ultérieure avec le module PowerShell Microsoft Graph.
  • Rôle Administrateur général , requis uniquement pour la configuration initiale. Utilisez Privileged Identity Management (PIM) pour activer ce rôle au moment voulu.
  • Le rôle « Administrateur d’applications cloud » ou Administrateur d’applications pour accorder des permissions déléguées Microsoft Graph pour les opérations de gestion des agents.

Pour vérifier que votre environnement est prêt :

  1. Assurez-vous de disposer des autorisations nécessaires pour créer des applications et des principaux de service dans votre tenant Microsoft Entra ID.
  2. Si vous effectuez un déploiement sur Azure, confirmez votre abonnement et votre groupe de ressources.
  3. Passez en revue la documentation de votre plateforme d’agent, par exemple AWS Bedrock ou n8n.

Pourquoi vous avez besoin d’une intégration d’agent tiers

Les organisations utilisent des agents IA à partir de plusieurs plateformes, telles que AWS Bedrock, n8n et d’autres. Ces agents doivent souvent :

  • Appelez Microsoft API telles que les services Microsoft Graph et Azure.
  • Accédez à vos API et ressources internes.
  • Authentifiez-vous en toute sécurité sans stocker de secrets dans le code ou la configuration.

Identifiant d’assistant Microsoft Entra fournit un service d’identité centralisé et sécurisé que les agents tiers peuvent utiliser pour acquérir des jetons à la demande, sans gérer directement les secrets ou les certificats. À l’aide de Identifiant d’assistant Microsoft Entra, vous pouvez :

  • Supprimez la nécessité pour les agents de gérer les informations d’identification directement.
  • Utilisez la fédération des identités de charge de travail pour les agents s’exécutant en dehors de Azure.
  • La solution prend en charge plusieurs modèles d’authentification, notamment les informations d’identification client, l’identité fédérée et l’authentification « on-behalf-of ».
  • Intégrez-vous à des plateformes d’agents tierces à l’aide du SDK d’authentification Microsoft Entra ID (sidecar).

Modèles d’intégration pour les agents tiers

Pour intégrer des agents tiers à Identifiant d’assistant Microsoft Entra, choisissez parmi les modèles suivants :

Utiliser le Kit de développement logiciel (SDK) d’authentification Microsoft Entra ID (sidecar)

Le modèle sidecar exécute le SDK Microsoft Entra ID Auth (sidecar) comme conteneur compagnon aux côtés de votre agent. L’agent appelle le sidecar pour demander des jetons pour les appels API. L’agent ne manipule jamais directement les informations d’identification ; il délègue l’acquisition des jetons au sidecar.

Meilleur pour :

  • Agents conteneurisés sur Docker ou Kubernetes.
  • Les agents Amazon Web Services AWS Bedrock s’exécutent dans votre propre environnement d’orchestration.
  • Développement local avec Docker Compose.
  • Les organisations utilisent déjà l’infrastructure de conteneur.

Plateformes prises en charge :

  • AWS Bedrock, y compris Claude et d’autres modèles de base.
  • Modèles locaux de grande langue (LLMs) tels que Ollama avec LangChain.
  • Tout agent conteneurisé.

Avantages :

  • Code de l’agent sans informations d’identification.
  • Fonctionne avec n’importe quel agent conteneurisé.
  • Développement local facile avec Docker Compose.
  • Peut être déployé sur Azure Container Apps, Kubernetes ou localement.

Considération:

  • Nécessite la gestion d’un deuxième conteneur.

Le diagramme suivant montre l'architecture du sidecar. Un conteneur d’agent et un conteneur sidecar s’exécutent conjointement dans le même environnement d’orchestration. L’agent demande des jetons à partir du sidecar, qui communique avec Identifiant d’assistant Microsoft Entra pour acquérir des jetons d’accès.

Schéma illustrant l’architecture du modèle sidecar, avec un conteneur d’agent et un conteneur sidecar exécutés dans le même environnement d’orchestration, le sidecar envoyant une requête à Microsoft Entra ID pour demander des jetons.

Utilisez la fédération des identités de charge de travail (échange direct d’identités).

Le modèle de fédération repose sur la fédération d’identités de charge de travail afin d’échanger directement les informations d’identification provenant de fournisseurs d’identité externes, tels que le service AWS Security Token Service, contre des jetons Microsoft Entra ID. Ce modèle n’a pas besoin d’un side-car.

Meilleur pour :

  • Agents AWS qui utilisent STS et OIDC.
  • Organisations qui disposent déjà d’une infrastructure de fédération.
  • Agents ne pouvant pas exécuter de conteneurs.

Plateformes prises en charge :

  • Identité de charge de travail GCP → Identifiant d’assistant Microsoft Entra.
  • AWS STS → Identifiant d’assistant Microsoft Entra.

Avantages :

  • Pas de side-car requis.
  • Utilise l’infrastructure existante dans AWS et d’autres plateformes.
  • Échange de jetons direct au niveau de la couche d’identité.

Exigences:

  • Une information d’identification fédérée préconfigurée dans Microsoft Entra ID.
  • Plateforme d’agent qui prend en charge OIDC ou STS.

Le schéma suivant montre le flux de fédération. Un agent sur une plateforme tierce s’authentifie via son fournisseur d’identité de charge de travail natif, échange le jeton OIDC obtenu pour un jeton Microsoft Entra, puis appelle vos API.

Diagram qui montre le flux du modèle de fédération où un agent de plateforme tiers échange un jeton OIDC via Identifiant d’assistant Microsoft Entra pour accéder à vos API ou aux API Microsoft.

Comprendre le flux de jetons

Les deux modèles suivent le même flux de jetons de base :

  1. L’agent demande un jeton. L’agent, ou le sidecar agissant pour le compte de l’agent, appelle Microsoft Entra ID avec des informations d’authentification.
  2. Microsoft Entra valide l’identité. Microsoft Entra vérifie l'identité de l'agent par le biais d'informations d'identification client, d'informations d'identification fédérées ou d'une autre méthode prise en charge.
  3. Microsoft Entra retourne un jeton. L’agent reçoit un jeton d’accès Microsoft Entra.
  4. L’agent appelle l’API. L’agent utilise le jeton pour s’authentifier auprès de Microsoft ou des API personnalisées.
  5. L’API valide le jeton. L’API vérifie la signature et les revendications du jeton, puis accorde l’accès.

Scénarios d’intégration courants

Agent AWS Bedrock appelant Microsoft Graph

Un agent AWS Bedrock, tel que Claude, doit interroger des données Microsoft 365 ou gérer des ressources via Microsoft Graph. Le modèle sidecar convient parfaitement à ce scénario. Pour intégrer un agent AWS Bedrock à l’aide du modèle sidecar :

  1. Déployez l’agent et le side-car sur AWS ou votre propre infrastructure.
  2. Configurez une identité d’agent dans Microsoft Entra avec des autorisations pour Microsoft Graph.
  3. L’agent appelle le sidecar afin d’obtenir un jeton.
  4. Le sidecar récupère un jeton auprès de Microsoft Entra ID.
  5. L’agent utilise le jeton pour appeler Microsoft Graph.

Pour obtenir des instructions pas à pas, consultez Secure an Amazon Bedrock agent with Identifiant d’assistant Microsoft Entra.

n8n agent appelant Microsoft Graph et MCP Server for Enterprise

Un agent n8n doit accéder aux données Microsoft 365 via Microsoft Graph ou le serveur MCP Microsoft Graph pour Entreprise. Ce scénario utilise le nœud de communauté n8n-nodes-entraagentid pour gérer l’acquisition de jetons directement dans les flux de travail n8n. Pour installer un agent n8n :

  1. Déployez n8n sur Azure Container Apps à l’aide de l’interface CLI développeur Azure (azd).
  2. Configurez une identité d’agent dans Microsoft Entra avec des autorisations pour Microsoft Graph.
  3. Le workflow n8n utilise le nœud communautaire pour acquérir un jeton de Identifiant d’assistant Microsoft Entra.
  4. L’agent utilise le jeton pour appeler Microsoft Graph ou le serveur MCP pour Entreprise.

Pour des instructions détaillées, consultez Sécuriser un agent n8n avec l'ID d'agent Microsoft Entra.

Développement local avec Ollama

Vous développez avec un LLM local comme Ollama et souhaitez tester l’authentification avant le déploiement. Utilisez le modèle sidecar avec Docker Compose. Pour tester localement :

  1. Exécutez l’agent et le sidecar avec Docker Compose.
  2. L’agent appelle localhost:7000/token afin de demander un jeton au sidecar.
  3. Le sidecar récupère un jeton auprès de Microsoft Entra ID.
  4. Testez localement le comportement de l’agent avant le déploiement.

Pour obtenir des instructions détaillées, consultez Exécuter le sidecar pour le développement local.

Feuille de route d’ensemble

Utilisez le tableau suivant pour identifier les étapes de votre modèle choisi :

Étape Modèle Tâche
1 Les deux Configurez l’identité et les autorisations de l’agent dans Microsoft Entra.
2 Les deux Choisissez un modèle d’intégration : sidecar ou fédération.
3 Sidecar Déployez les conteneurs de l’agent et du sidecar, puis réalisez des tests en environnement local.
4 Sidecar Déployez en production sur Azure Container Apps, Kubernetes ou une autre plateforme.
5 Fédération Configurez les informations d’identification d’identité fédérée dans Microsoft Entra.
6 Fédération Déployez l’agent sur la plateforme cible.

Bonnes pratiques de sécurité

Lorsque vous intégrez des agents tiers, suivez ces principes de sécurité :

  • N’incorporez jamais d’informations d’identification dans le code de l’agent. Utilisez Identifiant d’assistant Microsoft Entra pour acquérir des jetons dynamiquement.
  • Utilisez le privilège minimum. Accordez aux identités d’agent uniquement les autorisations nécessaires via des rôles ou des étendues.
  • Valider l’audience et l’émetteur des jetons. Vérifiez systématiquement que les jetons proviennent bien de votre tenant Microsoft Entra ID.
  • Faites pivoter régulièrement les identifiants. Si vous utilisez des secrets des clients, renouvelez-les selon un programme. Considérez plutôt les informations d’identification fédérées.
  • Surveillez l’utilisation des jetons. Utilisez les journaux de Microsoft Entra pour suivre quels agents accèdent à quelles API.
  • Maintenez le SDK d’authentification Microsoft Entra ID (sidecar) à jour. Les mises à jour de sécurité et de compatibilité sont publiées régulièrement.

Résoudre les problèmes courants

Si vous rencontrez des problèmes pendant l’intégration, utilisez les instructions suivantes pour identifier la cause et la résolution :

Problème Cause Solution
L'agent ne peut pas atteindre le sidecar Problème de configuration réseau ou sidecar ne fonctionne pas Vérifiez que le side-car est en cours d’exécution, vérifiez dns et réseau, puis confirmez la liaison de port. Le port par défaut est 7000.
Sidecar ne parvient pas à acquérir le jeton échec de l’authentification Microsoft Entra Vérifiez les informations d’identification de l’identité de l’agent, contrôlez les autorisations de Microsoft Entra et passez en revue l’ID du locataire ainsi que l’ID client.
La requête de jeton renvoie un 401 Informations d’identification non valides Microsoft Entra ou informations d’identification fédérées non configurées Confirmez l’exactitude des informations d’identification et vérifiez que les informations d’identification d’identité fédérée sont correctement configurées si vous utilisez le modèle de fédération.
L’API rejette le jeton Le jeton ne possède pas l’étendue ou les autorisations requises. Ajoutez les autorisations d’API requises à l’identité de l’agent et demandez un jeton avec l’étendue correcte.

Contenu connexe

  • Last updated on