Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps

  • Article

S’applique à : Azure Logic Apps (Consommation + Standard)

Lorsque vous utilisez une identité managée pour authentifier l’accès ou les connexions aux ressources protégées par Microsoft Entra à partir de votre flux de travail d’application logique, vous n’avez pas besoin de fournir des informations d’identification, des secrets ou des jetons Microsoft Entra. Dans Azure Logic Apps, certaines opérations de connecteur prennent en charge l’utilisation d’une identité managée lorsque vous devez authentifier l’accès aux ressources protégées par l’ID Microsoft Entra. Azure gère cette identité et sécurise les informations d’authentification dans la mesure où vous n’avez pas à gérer ces informations sensibles. Pour plus d’informations, consultez Que sont les identités managées pour les ressources Azure ?.

Azure Logic Apps prend en charge l’identité managée affectée par le système et l’identité managée affectée par l’utilisateur. La liste suivante décrit quelques différences entre ces types d’identité managée :

  • Une ressource d’application logique peut activer et utiliser une seule identité affectée par le système.

  • Une ressource d’application logique peut partager la même identité affectée par l’utilisateur dans un groupe d’autres ressources d’application logique.

Ce guide explique comment effectuer les tâches suivantes :

  • Activez et configurez l’identité managée affectée par le système pour votre ressource d’application logique. Ce guide fournit un exemple qui montre comment utiliser l’identité pour l’authentification.

  • Créez et configurez une identité affectée par l’utilisateur. Ce guide montre comment créer une identité affectée par l’utilisateur à l’aide du modèle Portail Azure et du modèle Azure Resource Manager (modèle ARM) et comment utiliser l’identité pour l’authentification. Pour Azure PowerShell, Azure CLI et l’API REST Azure, consultez la documentation suivante :

Outil Documentation
Azure PowerShell Créer une identité affectée par l’utilisateur
Azure CLI Créer une identité affectée par l’utilisateur
API REST Azure Créer une identité affectée par l’utilisateur

Applications logiques Consommation et Standard

En fonction du type de ressource de votre application logique, vous pouvez activer l’identité affectée par le système, l’identité affectée par l’utilisateur ou les deux à la fois :

Application logique Environnement Prise en charge des identités managées
Consommation - Azure Logic Apps multilocataire

- Environnement de service d’intégration (ISE)		 - Votre application logique peut activer soit l’identité affectée par le système soit l’identité affectée par l’utilisateur.

- Vous pouvez utiliser l’identité managée au niveau de la ressource d’application logique et au niveau de la connexion.

- Si vous activez l’identité affectée par l’utilisateur, votre application logique ne peut avoir qu’une seule identité affectée par l’utilisateur à la fois.
Standard - Azure Logic Apps monolocataire

- App Service Environment v3 (ASEv3)

- Logic Apps avec Azure Arc		 - Vous pouvez activer à la fois l’identité affectée par le système, qui est activée par défaut et l’identité affectée par l’utilisateur en même temps.

- Vous pouvez utiliser l’identité managée au niveau de la ressource d’application logique et au niveau de la connexion.

- Si vous activez l’identité affectée par l’utilisateur, votre ressource d’application logique peut avoir plusieurs identités affectées par l’utilisateur en même temps.

Pour plus d’informations sur les limites d’identité managée dans Azure Logic Apps, consultez Limites sur les identités managées pour les applications logiques. Pour plus d’informations sur les types de ressources et environnements d’application logique Consommation et Standard, consultez la documentation suivante :

Où utiliser une identité managée

Dans Azure Logic Apps, seules les opérations intégrées et managées spécifiques qui prennent en charge OAuth avec l’ID Microsoft Entra peuvent utiliser une identité managée pour l’authentification. Les tableaux suivants fournissent uniquement un exemple de sélection. Pour obtenir une liste plus complète, consultez les types d’authentification pour les déclencheurs et les actions qui prennent en charge l’authentification et les services Azure qui prennent en charge l’authentification Microsoft Entra avec des identités managées.

Pour un flux de travail d’application logique Consommation, le tableau suivant répertorie les connecteurs qui prennent en charge l’authentification d’identité managée :

Type de connecteur Connecteurs pris en charge
Intégré - Gestion des API Azure
- Azure App Services
- Azure Functions
- HTTP
- HTTP + Webhook

Remarque : Les opérations HTTP peuvent authentifier les connexions aux comptes Stockage Azure derrière des pare-feux Azure avec l’identité affectée par le système. Toutefois, elles ne prennent pas en charge l’identité managée affectée par l’utilisateur pour authentifier les mêmes connexions.
Géré - Azure App Service
- Azure Automation
- Stockage Blob Azure
- Azure Container Instance
- 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
- Files d’attente Azure
- Azure Resource Manager
- Azure Service Bus
- Azure Sentinel
- Stockage Table Azure
- Machine virtuelle Azure
- HTTP avec Microsoft Entra ID
- SQL Server

Prérequis

Activer l’identité affectée par le système dans le Portail Azure

  1. Dans le portail Azure, ouvrez votre ressource d’application logique.

  2. Dans le menu de l’application logique, sous Paramètres, sélectionnez Identité.

  3. Dans la page Identité , sous Système affecté, sélectionnez Sur>Enregistrer. Quand Azure vous invite à confirmer l’opération, sélectionnez Oui.

    Screenshot shows Azure portal, Consumption logic app, Identity page, and System assigned tab with selected options, On and Save.

    Remarque

    Si vous recevez une erreur indiquant que vous ne pouvez avoir qu’une seule identité managée, cela signifie que votre ressource d’application logique est déjà associée à l’identité affectée par l’utilisateur. Avant de pouvoir ajouter l’identité affectée par le système, vous devez d’abord supprimer l’identité affectée par l’utilisateur de votre ressource d’application logique.

    Votre ressource d’application logique peut désormais utiliser l’identité affectée par le système. Cette identité est inscrite auprès de Microsoft Entra ID et est représentée par un ID d’objet.

    Screenshot shows Consumption logic app, Identity page, and object ID for system-assigned identity.

    Propriété Valeur Description
    ID de l’objet (principal) <identity-resource-ID> GUID (identificateur global unique) qui représente l’identité affectée par le système pour votre application logique dans un locataire Microsoft Entra.

  4. Suivez maintenant les étapes qui donnent à cette identité l’accès à la ressource plus loin dans ce guide.

Activer une identité affectée par le système dans un modèle ARM

Pour automatiser la création et le déploiement de ressources d’application logique, vous pouvez utiliser un modèle ARM. Pour activer l’identité affectée par le système pour votre ressource d’application logique dans le modèle, ajoutez l’objet identity et la propriété enfant type à la définition de ressource de l’application logique dans le modèle, par exemple :

{
   "apiVersion": "2016-06-01",
   "type": "Microsoft.logic/workflows",
   "name": "[variables('logicappName')]",
   "location": "[resourceGroup().location]",
   "identity": {
      "type": "SystemAssigned"
   },
   "properties": {},
   <...>
}

Quand Azure crée la définition de ressource de votre application logique, l’identityobjet obtient les propriétés supplémentaires suivantes :

"identity": {
   "type": "SystemAssigned",
   "principalId": "<principal-ID>",
   "tenantId": "<Azure-AD-tenant-ID>"
}
Propriété (JSON) Valeur Description
principalId <principal-ID> Identificateur global unique (GUID) de l’objet du principal de service pour l’identité managée qui représente votre application logique dans le locataire Microsoft Entra. Ce GUID apparaît parfois sous la forme d’un « ID d’objet » ou objectID.
tenantId <Azure-AD-tenant-ID> Identificateur global unique (GUID) représentant le locataire Microsoft Entra où l’application logique est maintenant membre. À l’intérieur du locataire Microsoft Entra, le principal du service a le même nom que l’instance d’application logique.

Créer une identité affectée par l’utilisateur dans le portail Azure

Avant de pouvoir activer l’identité affectée par l’utilisateur sur votre ressource d’application logique Consommation ou la ressource d’application logique Standard, vous devez créer cette identité en tant que ressource Azure distincte.

  1. Dans la zone de recherche Portail Azure, entrez des identités managées, puis sélectionnez Identités managées.

    Screenshot shows Azure portal with selected option named Managed Identities.

  2. Dans la page Identités managées , sélectionnez Créer.

    Screenshot shows Managed Identities page and selected option for Create.

  3. Fournissez des informations sur votre identité managée, puis sélectionnez Vérifier + Créer, par exemple :

    Screenshot shows page named Create User Assigned Managed Identity, with managed identity details.

    Propriété Obligatoire Value Description
    Abonnement Oui <Azure-subscription-name> Nom de l’abonnement Azure
    Groupe de ressources Oui <nom-groupe-de-ressources-Azure> Le nom du groupe de ressources Azure. Créez un groupe, ou sélectionnez un groupe existant. Cet exemple crée un groupe nommé fabrikam-managed-identities-RG.
    Région Oui <Azure-region> Région Azure où stocker les informations relatives à votre ressource. Cet exemple utilise la région USA Ouest.
    Nom Oui <nom-identité-affectée-par-utilisateur> Nom à donner à votre identité affectée par l’utilisateur. Cet exemple utilise Fabrikam-user-assigned-identity.

    Une fois les informations validées, Azure crée votre identité managée. À présent, vous pouvez ajouter l’identité affectée par l’utilisateur à votre ressource d’application logique.

Ajouter une identité affectée par l’utilisateur à l’application logique dans le portail Azure

  1. Dans le portail Azure, ouvrez votre ressource d’application logique.

  2. Dans le menu de l’application logique, sous Paramètres, sélectionnez Identité.

  3. Dans la page Identité, sélectionnez Ajouter affecté par>l’utilisateur.

    Screenshot shows Consumption logic app and Identity page with selected option for Add.

  4. Dans le volet Ajouter une identité managée affectée par l’utilisateur, effectuez les étapes suivantes :

    1. Dans la liste des abonnements , sélectionnez votre abonnement Azure.

    2. Dans la liste contenant toutes les identités managées de votre abonnement, sélectionnez l’identité affectée par l’utilisateur souhaitée. Pour filtrer la liste, dans la zone de recherche Identités managées affectées par l’utilisateur, entrez le nom de l’identité ou du groupe de ressources.

      Screenshot shows Consumption logic app and selected user-assigned identity.

    3. Une fois que vous avez terminé, sélectionnez Ajouter.

      Notes

      Si vous recevez une erreur indiquant que vous ne pouvez avoir qu’une seule identité managée, cela signifie que votre application logique est déjà associée à l’identité affectée par le système. Avant de pouvoir ajouter l’identité affectée par l’utilisateur, vous devez d’abord désactiver l’identité affectée par le système.

    Votre application logique est désormais associée à l’identité managée affectée par l’utilisateur.

    Screenshot shows Consumption logic app with associated user-assigned identity.

  5. Suivez maintenant les étapes qui donnent à cette identité l’accès à la ressource plus loin dans ce guide.

Créer une identité affectée par l’utilisateur dans un modèle ARM

Pour automatiser la création et le déploiement de ressources d’application logique, vous pouvez utiliser un modèle ARM. Ces modèles prennent en charge les identités affectées par l’utilisateur pour l’authentification.

Dans la section resources de votre modèle, la définition de ressource de votre application logique nécessite les éléments suivants :

  • Objet identity dont la propriété type a la valeur UserAssigned

  • Objet userAssignedIdentities enfant qui spécifie la ressource et le nom affectés par l’utilisateur

Cet exemple montre une ressource d’application logique consommation et une définition de flux de travail pour une requête HTTP PUT avec un objet non paramétrable identity . La réponse à la demande PUT et à l’opération GET suivante inclut également cet identity objet :

{
   "$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 votre modèle inclut également la définition de ressource de l’identité managée, vous pouvez paramétrer l’objet identity. L’exemple suivant montre comment l’objet enfant userAssignedIdentities fait référence à une userAssignedIdentityName variable que vous définissez dans la section de variables votre modèle. Cette variable référence l’ID de ressource de l’identité affectée par l’utilisateur.

{
   "$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": {}
      }
  ]
}

Accorder à une identité l’accès aux ressources

Pour pouvoir vous servir de l’identité managée de votre application logique dans le cadre de l’authentification, vous devez configurer l’accès de cette identité sur la ressource Azure où vous souhaitez utiliser l’identité. La façon dont vous configurez l’accès varie en fonction de la ressource à laquelle vous souhaitez que l’identité accède.

Notes

Quand une identité managée a accès à une ressource Azure dans le même abonnement, l’identité ne peut accéder qu’à cette ressource. Toutefois, dans certains déclencheurs et actions qui prennent en charge les identités managées, vous devez d’abord sélectionner le groupe de ressources Azure qui contient la ressource cible. Si l’identité ne dispose pas d’un accès au niveau du groupe de ressources, aucune ressource de ce groupe n’est listée malgré l’accès à la ressource cible.

Pour gérer ce comportement, vous devez également autoriser l’identité à accéder au groupe de ressources, et pas seulement à la ressource. De même, si vous devez sélectionner votre abonnement avant de pouvoir sélectionner la ressource cible, vous devez autoriser l’identité à accéder à l’abonnement.

Dans certains cas, vous devrez peut-être avoir besoin de l’identité pour accéder à la ressource associée. Par exemple, supposons que vous disposez d’une identité managée pour une application logique qui a besoin d’un accès pour mettre à jour les paramètres de l’application pour cette même application logique à partir d’un flux de travail. Vous devez accorder à cette identité l’accès à l’application logique associée.

Par exemple, pour accéder à un compte Stockage Blob Azure avec votre identité managée, vous devez configurer l’accès à l’aide du contrôle d’accès en fonction du rôle Azure (Azure RBAC) et affecter le rôle approprié pour cette identité au compte de stockage. Les étapes de cette section décrivent comment effectuer cette tâche à l’aide du portail Azure et du modèle Azure Resource Manager (modèle ARM). Pour Azure PowerShell, Azure CLI et l’API REST Azure, consultez la documentation suivante :

Outil Documentation
Azure PowerShell Ajouter une attribution de rôle
Azure CLI Ajouter une attribution de rôle
API REST Azure Ajouter une attribution de rôle

Toutefois, pour accéder à un coffre de clés Azure avec votre identité managée, vous devez créer une stratégie d’accès pour cette identité sur votre coffre de clés et affecter les autorisations appropriées pour cette identité sur ce coffre de clés. Les étapes ultérieures de cette section décrivent comment effectuer cette tâche à l’aide du portail Azure. Pour les modèles Resource Manager, PowerShell et Azure CLI, consultez la documentation suivante :

Outil Documentation
Modèle Azure Resource Manager (modèle ARM) Définition de la ressource de stratégie d’accès Key Vault
Azure PowerShell Attribuer une stratégie d’accès Key Vault
Azure CLI Attribuer une stratégie d’accès Key Vault

Attribuer un accès d’identité managée basée sur le rôle dans le Portail Azure

Pour utiliser une identité managée pour l’authentification, certaines ressources Azure, telles que les comptes de stockage Azure, requièrent que vous affectiez cette identité à un rôle disposant des autorisations appropriées sur la ressource cible. D’autres ressources Azure, telles que les coffres de clés Azure, requièrent la création d’une stratégie d’accès disposant des autorisations appropriées sur la ressource cible pour cette identité.

  1. Dans le Portail Azure, ouvrez la ressource où vous souhaitez utiliser l’identité.

  2. Dans le menu des ressources, sélectionnez Contrôle d’accès (IAM)>Ajouter>une attribution de rôle.

    Remarque

    Si l’option Ajouter une attribution de rôle est désactivée, vous n’avez pas les autorisations pour attribuer les rôles. Pour plus d’informations, consultez Rôles intégrés Microsoft Entra.

  3. À présent, attribuez le rôle nécessaire à votre identité managée. Dans l’onglet Rôle, attribuez un rôle à votre identité qui lui permette d’accéder à la ressource actuelle.

    Pour cet exemple, attribuez le rôle nommé Contributeur aux données Blob de stockage, qui comprend un accès en écriture aux objets blob dans un conteneur de Stockage Azure. Pour plus d’informations sur des rôles de conteneur de stockage spécifiques, consultez Rôles pouvant accéder aux objets blob dans un conteneur Stockage Azure.

  4. Ensuite, choisissez l’identité managée dans laquelle vous souhaitez affecter le rôle. Sous Attribuer l’accès à, sélectionnez Identité managée>Ajouter des membres.

  5. En fonction du type de votre identité managée, sélectionnez ou fournissez les valeurs suivantes :

    Type Instance de service Azure Abonnement Membre
    Attribué par le système Application logique <Azure-subscription-name> <your-logic-app-name>
    Affecté par l’utilisateur Non applicable <Azure-subscription-name> <your-user-assigned-identity-name>

    Pour plus d’informations sur l’attribution de rôles, consultez Affecter des rôles à l’aide du Portail Azure.

  6. Une fois que vous avez fini, vous pouvez utiliser l’identité pour authentifier l’accès aux déclencheurs et aux actions qui prennent en charge les identités managées.

Pour plus d’informations générales sur cette tâche, consultez Affecter un accès d’identité managée à une autre ressource à l’aide d’Azure RBAC.

Créer une stratégie d’accès dans le portail Azure

Pour utiliser une identité managée pour l’authentification, certaines ressources Azure, telles que les coffres de clés Azure, requièrent la création d’une stratégie d’accès dotée des autorisations appropriées sur la ressource cible pour cette identité. D’autres ressources Azure, telles que les comptes de stockage Azure, requièrent l’affectation de cette identité à un rôle disposant des autorisations appropriées sur la ressource cible.

  1. Dans le portail Azure, ouvrez la ressource cible où vous souhaitez utiliser l’identité. Cet exemple utilise un coffre de clés Azure comme ressource cible.

  2. Dans le menu de la ressource, sélectionnez Stratégies d’accès>Créer, ce qui ouvre le volet Créer une stratégie d’accès.

    Notes

    Si la ressource ne dispose pas de l’option Stratégies d’accès, essayez d’affecter une affectation de rôle à la place.

    Screenshot shows Azure portal and key vault example with open pane named Access policies.

  3. Sous l’onglet Autorisations, sélectionnez les autorisations requises dont l’identité a besoin pour accéder à la ressource cible.

    Par exemple, pour utiliser l’identité avec l’opération Lister les secrets du connecteur Azure Key Vault managé, l’identité a besoin des autorisations Lister. Ainsi, dans la colonne Autorisations du secret, sélectionnez Lister.

    Screenshot shows Permissions tab with selected List permissions.

  4. Ensuite, sélectionnez Suivant. Sous l’onglet Principal, recherchez et sélectionnez l’identité managée, qui est une identité affectée par l’utilisateur dans cet exemple.

  5. Ignorez l’étape Application facultative, sélectionnez Suivant, puis terminez la création de la stratégie d’accès.

La section suivante décrit l’utilisation d’une identité managée visant à authentifier l’accès pour un déclencheur ou une action. L’exemple continue avec les étapes d’une section précédente où vous configurez l’accès pour une identité managée à l’aide de RBAC, et n’utilise pas Azure Key Vault comme exemple. Toutefois, les étapes générales d’utilisation d’une identité managée pour l’authentification sont les mêmes.

Authentifier l’accès avec des identités managées

Une fois que vous avez activé l’identité managée pour votre ressource d’application logique et accordé à cette identité l’accès à la ressource ou entité cibles, vous pouvez utiliser cette identité dans des déclencheurs et actions prenant en charge les identités managées.

Important

Si vous avez une fonction Azure dans laquelle vous voulez utiliser l’identité affectée par le système, commencez par activer l’authentification pour les fonctions Azure.

Ces étapes montrent comment utiliser l’identité managée avec un déclencheur ou une action via le portail Azure. Pour spécifier l’identité managée dans la définition JSON sous-jacente d’un déclencheur ou d’une action, voir Authentification d’identité managée.

  1. Dans le portail Azure, ouvrez votre ressource d’application logique.

  2. Si ce n’est encore fait, ajoutez le déclencheur ou l’action prenant en charge les identités managées.

    Remarque

    Toutes les opérations de connecteur ne prennent pas en charge l’ajout d’un type d’authentification. Pour plus d’informations, consultez Types d’authentification pour les déclencheurs et les actions qui prennent en charge l’authentification.

  3. Sur le déclencheur ou l’action que vous avez ajouté, procédez comme suit :

    • Opérations de connecteur intégrées qui prennent en charge l’authentification d’identité managée

      1. Dans la liste Ajouter un nouveau paramètre, ajoutez la propriété Authentification si la propriété n’apparaît pas déjà.

        Screenshot shows Consumption workflow with built-in action and opened list named Add new parameter, with selected option for Authentication.

      2. Dans la liste Type d’authentification, sélectionnez Identité managée.

        Screenshot shows Consumption workflow with built-in action and opened list named Authentication type, with selected option for Managed identity.

      Pour plus d’informations, consultez Exemple : Authentifier le déclencheur ou l’action intégré avec une identité managée.

    • Opérations de connecteur managé qui prennent en charge l’authentification avec des identités managées

      1. Dans la page de sélection du locataire, sélectionnez Se connecter avec une identité managée. Par exemple :

        Screenshot shows Consumption workflow with Azure Resource Manager action and selected option for Connect with managed identity.

      2. Dans la page suivante, renseignez le champ Nom de la connexion.

      3. Pour le type d’authentification, choisissez l’une des options suivantes en fonction de votre connecteur managé :

        • Authentification unique : ces connecteurs ne prennent en charge qu’un seul type d’authentification. Dans la liste Identité managée, sélectionnez l’identité managée actuellement activée si cela n’est pas déjà fait, puis sélectionnez Créer. Par exemple :

          Screenshot shows Consumption workflow, connection name box, and selected option for system-assigned managed identity.

        • Authentification multiple: ces connecteurs affichent plusieurs types d’authentification, mais vous ne pouvez en sélectionner qu’un seul. Dans la liste Type d’authentification, sélectionnez Identité managée Logic Apps>Créer. Par exemple :

          Screenshot shows Consumption workflow, connection name box, and selected option for Logic Apps Managed Identity.

        Pour plus d’informations, consultez Exemple : Authentifier le déclencheur ou l’action du connecteur managé avec une identité managée.

Exemple : Authentifier le déclencheur ou l’action intégré avec une identité managée

Le déclencheur ou l’action HTTP intégré peut utiliser l’identité affectée par le système que vous activez sur votre ressource d’application logique. En général, le déclencheur ou l’action HTTP utilise les propriétés suivantes pour spécifier la ressource ou l’entité à laquelle vous souhaitez accéder :

Propriété Obligatoire Description
Méthode Oui Méthode HTTP utilisée par l’opération que vous souhaitez exécuter
URI Oui URL de point de terminaison pour accéder à la ressource ou entité Azure cibles. La syntaxe de l’URI comprend généralement l’ID de ressource pour la ressource ou le service Azure.
En-têtes Non Toute valeur d’en-tête que vous devez ou souhaitez inclure dans la demande sortante, telle que le type de contenu
Requêtes Non Tous les paramètres de requête que vous devez ou voulez inclure dans la demande. Par exemple, les paramètres de requête pour une opération spécifique ou pour la version d’API de l’opération que vous souhaitez exécuter.
Authentification Oui Type d’authentification à utiliser pour authentifier l’accès à la ressource ou entité cibles

À titre d’exemple, supposons que vous souhaitez exécuter l’opération de capture instantanée d’objet blob sur un blob dans le compte de Stockage Azure où vous avez précédemment configuré l’accès pour votre identité. Toutefois, le connecteur de Stockage Blob Azure ne propose pas cette opération actuellement. Au lieu de cela, vous pouvez l’exécuter à l’aide de l’action HTTP ou d’une autre opération de l’API REST du service BLOB.

Important

Pour accéder aux comptes de stockage Azure derrière des pare-feu en utilisant le connecteur Azure Blob et des identités managées, veillez à configurer également votre compte de stockage avec l’exception qui autorise l’accès de services Microsoft approuvés.

Pour exécuter l’opération de capture instantanée d’objet blob, l’action HTTP spécifie les propriétés suivantes :

Propriété Obligatoire Valeur d'exemple Description
Méthode Oui PUT Méthode HTTP utilisée par l’opération de capture instantanée d’objet blob
URI Oui https://<storage-account-name>/<folder-name>/{name} ID de ressource d’un fichier de Stockage Blob Azure dans l’environnement global (public) Azure qui utilise cette syntaxe
En-têtes Pour Stockage Azure x-ms-blob-type = BlockBlob

x-ms-version = 2019-02-02

x-ms-date = @{formatDateTime(utcNow(),'r')}

 Les valeurs d’en-tête x-ms-blob-type, x-ms-version et x-ms-date sont requises pour les opérations du service Stockage Azure.

Important ! Dans le déclencheur HTTP sortant et les demandes d’action pour Stockage Azure, l’en-tête requiert la propriété x-ms-version et la version de l’API pour l’opération que vous souhaitez exécuter. La valeur x-ms-date doit être la date actuelle. Dans le cas contraire, votre workflow échoue avec une erreur 403 FORBIDDEN. Pour obtenir la date actuelle au format requis, vous pouvez utiliser l’expression dans l’exemple de valeur.

Pour plus d’informations, consultez la documentation suivante :

- En-têtes de demande – Capture instantanée d’objet blob
- Contrôle de version pour les services Stockage Azure
Requêtes Uniquement pour l’opération de capture instantanée de blob comp = snapshot Nom et valeur du paramètre de requête pour l’opération.

L’exemple suivant montre un exemple d’action HTTP avec toutes les valeurs de propriété précédemment décrites à utiliser pour l’opération Snapshot Blob :

Screenshot shows Azure portal, Consumption workflow, and HTTP action set up to access resources.

  1. Après avoir ajouté l’action HTTP, ajoutez la propriété Authentification à l’action HTTP. Dans la liste Ajouter un nouveau paramètre, sélectionnez Authentification.

    Screenshot shows Consumption workflow with HTTP action and opened Add new parameter list with selected property named Authentication.

    Remarque

    Tous les déclencheurs et toutes les actions ne vous permettent pas d’ajouter un type d’authentification. Pour plus d’informations, consultez Types d’authentification pour les déclencheurs et les actions qui prennent en charge l’authentification.

  2. Dans la liste Type d’authentification, sélectionnez Identité managée.

    Screenshot shows Consumption workflow, HTTP action, and Authentication property with selected option for Managed identity.

  3. Dans la liste des identités managées, sélectionnez les options disponibles en fonction de votre scénario.

    • Si vous configurez l’identité affectée par le système, sélectionnez Identité managée affectée par le système si cela n’est pas déjà fait.

      Screenshot shows Consumption workflow, HTTP action, and Managed identity property with selected option for System-assigned managed identity.

    • Si vous configurez une identité affectée par l’utilisateur, sélectionnez cette identité, si cela n’est pas déjà fait.

      Screenshot shows Consumption workflow, HTTP action, and Managed identity property with selected user-assigned identity.

    Cet exemple se poursuit avec l’identité managée affectée par le système.

  4. Sur certains déclencheurs et actions, la propriété Audience apparaît également pour vous permettre de définir l’ID de ressource cible. Affectez à la propriété Audience la valeur de l’ID de ressource de la ressource ou du service cible. Autrement, par défaut, la propriété Audience utilise l’ID de ressource https://management.azure.com/, qui est l’ID de ressource pour Azure Resource Manager.

    Par exemple, si vous souhaitez authentifier l’accès à une ressource de Coffre de clés dans le cloud global Azure, vous devez définir la propriété Audienceprécisément sur l’ID de ressource suivante : https://vault.azure.net. Cet ID de ressource spécifique n’a pas de barres obliques de fin. En réalité, l’inclusion d’une barre oblique de fin pourrait produire soit une erreur 400 Bad Request soit une erreur 401 Unauthorized.

    Important

    Vérifiez que l’ID de ressource cible correspond exactement à la valeur qu’attend Microsoft Entra ID, y compris les barres obliques de fin obligatoires. Par exemple, l’ID de ressource pour tous les comptes de Stockage Blob Azure requiert une barre oblique finale. Toutefois, l’ID de ressource pour un compte de stockage spécifique ne requiert pas de barre oblique finale. Vérifiez les ID de ressource des services Azure qui prennent en charge Microsoft Entra ID.

    Cet exemple définit la propriété Audience sur https://storage.azure.com/ afin que les jetons d’accès utilisés pour l’authentification soient valides pour tous les comptes de stockage. Toutefois, vous pouvez également spécifier l’URL du service racine, https://<your-storage-account>.blob.core.windows.net, pour un compte de stockage spécifique.

    Screenshot shows Consumption workflow, HTTP action, and Audience

    Pour plus d’informations sur l’autorisation d’accès avec l’ID Microsoft Entra pour Stockage Azure, consultez la documentation suivante :

  5. Continuez à créer le workflow comme vous le souhaitez.

Exemple : Authentifier un déclencheur ou une action de connecteur géré avec une identité managée

Le connecteur managé Azure Resource Manager a une action appelée Lire une ressource, qui peut utiliser l’identité managée que vous activez sur votre ressource d’application logique. Cet exemple montre comment utiliser l’identité managée affectée par le système.

  1. Une fois que vous avez ajouté l’action à votre workflow et sélectionné votre locataire Microsoft Entra, sélectionnez Se connecter avec une identité managée.

    Screenshot shows Consumption workflow, Azure Resource Manager action, and selected option for Connect with managed identity.

  2. Dans la page du nom de la connexion, indiquez un nom pour la connexion et sélectionnez l’identité managée à utiliser.

    L’action Azure Resource Manager est une action d’authentification unique. Par conséquent, la zone d’informations de connexion affiche une liste d’identités managées qui sélectionne automatiquement l’identité managée actuellement activée sur la ressource d’application logique. Si vous avez activé une identité managée affectée par le système, la liste Identité managée sélectionne Identité managée affectée par le système. Si vous avez activé une identité managée affectée par l’utilisateur à la place, la liste sélectionne cette identité.

    Si vous utilisez un déclencheur ou une action multi-authentification, tel que Stockage Blob Azure, la zone d’informations de connexion affiche une liste de types d’authentification qui inclut l’option Logic Apps Managed Identity entre autres types d’authentification.

    Dans cet exemple, Identité managée affectée par le système est la seule sélection disponible.

    Screenshot shows Consumption workflow and Azure Resource Manager action with connection name entered and selected option for System-assigned managed identity.

    Remarque

    Si l’identité managée n’est pas activée quand vous essayez de créer ou de modifier la connexion ou qu’elle a été supprimée alors qu’une connexion avec une identité managée existe encore, vous recevez une erreur indiquant que vous devez activer l’identité et accorder l’accès à la ressource cible.

  3. Quand vous êtes prêt, sélectionnez Créer.

  4. Une fois qu’il a réussi à créer la connexion, le concepteur peut extraire les valeurs, le contenu ou le schéma dynamiques à l’aide de l’authentification par identité managée.

  5. Continuez à créer le workflow comme vous le souhaitez.

Définition et connexions de ressources d’application logique qui utilisent une identité managée

Une connexion qui active et utilise une identité managée est un type particulier de connexion qui fonctionne uniquement avec une identité managée. Au moment de l’exécution, la connexion utilise l’identité managée qui est activée sur la ressource d’application logique. Au moment de l’exécution, le service Azure Logic Apps vérifie si un déclencheur et des actions de connecteur managé dans le workflow de l’application logique sont configurés pour utiliser l’identité managée et que toutes les autorisations requises sont configurées pour utiliser l’identité managée afin d’accéder aux ressources cibles spécifiées par le déclencheur et les actions. En cas de réussite, Azure Logic Apps récupère le jeton Microsoft Entra associé à l’identité managée et utilise cette identité pour authentifier l’accès à la ressource cible et effectuer l’opération configurée dans le déclencheur et les actions.

Dans une ressource d’application logique Consommation, la configuration de la connexion est enregistrée dans l’objet de la définition de ressource d’application parameters logique, qui contient l’objet $connections qui inclut des pointeurs vers l’ID de ressource de la connexion, ainsi que l’ID de ressource de l’identité, si l’identité affectée par l’utilisateur est activée.

Cet exemple montre à quoi ressemble la configuration lorsque l’application logique active l’identité managée affectée par le système :

"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}"
         }
      }
   }
}

Cet exemple montre à quoi ressemble la configuration lorsque l’application logique active une identité managée affectée par l’utilisateur :

"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}"
         }
      }
   }
}

Modèle ARM pour les connexions d’API et les identités managées

Si vous utilisez un modèle ARM pour automatiser le déploiement et que votre workflow comprend une connexion d’API, créée par un connecteur managé comme Office 365 Outlook, Azure Key Vault, etc., qui utilise une identité managée, vous devez effectuer une étape supplémentaire.

Dans un modèle ARM, la définition de ressource de connecteur sous-jacente diffère selon que vous disposez d’une application logique Consommation ou Standard et que le connecteur affiche des options d’authentification unique ou multiple.

Les exemples suivants s’appliquent aux ressources d’application logique Consommation et montrent comment la définition de ressource de connecteur sous-jacente diffère entre un connecteur à authentification unique, tel qu’Azure Automation et un connecteur multi-authentification, tel que Stockage Blob Azure.

Authentification unique

Cet exemple illustre la définition de ressource de connexion sous-jacente pour une action d’Azure Automation dans une application logique Consommation qui utilise une identité managée où la définition inclut les attributs :

  • La propriété kind a la valeur V1 pour une application logique Consommation.
  • La propriété parameterValueType est définie sur Alternative.
{
    "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"
    }
},

Authentification multiple

Cet exemple illustre la définition de ressource de connexion sous-jacente pour une action de Stockage Blob Azure dans une application logique Consommation qui utilise une identité managée où la définition inclut les attributs suivants :

  • La propriété kind a la valeur V1 pour une application logique Consommation.
  • L’objet parameterValueSet comprend une propriété name définie sur managedIdentityAuth, et une propriété values définie sur un objet vide.
{
    "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"
    }
}

Configurer le contrôle avancé sur l’authentification de la connexion d’API

Quand votre workflow utilise une connexion d’API, créée par un connecteur managé comme Office 365 Outlook, Azure Key Vault, etc., le service Azure Logic Apps communique avec la ressource cible, telle que votre compte de messagerie, votre coffre de clés, etc., à l’aide de deux connexions :

Conceptual diagram showing first connection with authentication between logic app and token store plus second connection between token store and target resource.

  • La connexion 1 est configurée avec l’authentification pour le magasin de jetons interne.

  • La connexion 2 est configurée avec l’authentification pour la ressource cible.

Dans une ressource d’application logique de consommation, la connexion 1 vous est abstraite sans aucune option de configuration. Dans le type de ressource de l’application logique standard, vous avez davantage de contrôle sur votre application logique. Par défaut, la connexion 1 est automatiquement configurée pour utiliser l’identité affectée par le système.

Toutefois, si votre scénario nécessite un contrôle plus précis de l’authentification des connexions d’API, vous pouvez éventuellement modifier l’authentification pour la connexion 1 de l’identité affectée par le système par défaut en la remplaçant par une identité quelconque affectée par l’utilisateur que vous avez ajoutée à votre application logique. Cette authentification s’applique à chaque connexion d’API, ce qui vous permet de combiner des identités affectées par le système et affectées par l’utilisateur sur différentes connexions à la même ressource cible.

Dans votre fichier connections.json de l’application logique standard, qui stocke des informations sur chaque connexion d’API, chaque définition de connexion comporte deux sections authentication, par exemple :

"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 première section authentication est mappée à la connexion 1. Cette section décrit l’authentification utilisée pour communiquer avec le magasin de jetons interne. Dans le passé, cette section était toujours définie sur ManagedServiceIdentity pour une application qui se déploie sur Azure, et elle ne proposait aucune option configurable.

  • La deuxième section authentication est mappée à la connexion 2. Cette section décrit l’authentification utilisée pour communiquer avec la ressource cible, qui peut varier en fonction du type d’authentification que vous sélectionnez pour cette connexion.

Pourquoi modifier l’authentification pour le magasin de jetons ?

Dans certains scénarios, vous souhaiterez peut-être partager et utiliser la même connexion d’API sur plusieurs applications logiques, sans ajouter l’identité affectée par le système pour chaque application logique à la stratégie d’accès de la ressource cible.

Dans d’autres scénarios, vous ne souhaiterez peut-être pas que l’identité affectée par le système soit entièrement configurée sur votre application logique, de sorte que vous pouvez modifier l’authentification en spécifiant une identité affectée par l’utilisateur et en désactivant complètement l’identité affectée par le système.

Modifier l’authentification pour le magasin de jetons

  1. Dans le portail Azure, ouvrez votre ressource d’application logique Standard.

  2. Dans le menu de ressources, sous Workflows, sélectionnez Connexions.

  3. Dans le volet Connexions, sélectionnez Vue JSON.

    Screenshot showing the Azure portal, Standard logic app resource,

  4. Dans l’éditeur JSON, recherchez la section managedApiConnections, qui contient les connexions d’API couvrant tous les workflows figurant dans votre ressource d’application logique.

  5. Recherchez la connexion dans laquelle vous souhaitez ajouter une identité managée affectée par l’utilisateur. Supposons, par exemple, que votre flux de travail dispose d’une connexion 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>"
}

  6. Dans la définition de la connexion, procédez comme suit :

    1. Recherchez la première section authentication. Si aucune propriété identity n’existe encore dans cette section authentication, l’application logique utilise implicitement l’identité affectée par le système.

    2. Ajoutez une propriété identity à l’aide de l’exemple de cette étape.

    3. Définissez la valeur de la propriété sur l’ID de ressource pour l’identité affectée par l’utilisateur.

    "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>"
}

  7. Dans le portail Azure, accédez à la ressource cible et accordez l’accès à l’identité managée affectée par l’utilisateur, en fonction des besoins de la ressource cible.

    Par exemple, pour Azure Key Vault, ajoutez l’identité aux stratégies d’accès du coffre de clés. Pour Stockage Blob Azure, affectez le rôle nécessaire pour l’identité au compte de stockage.

Désactiver l’identité managée

Pour cesser d’utiliser l’identité managée pour l’authentification, commencez par supprimer l’accès de l’identité à la ressource cible. Ensuite, sur votre ressource d’application logique, désactivez l’identité affectée par le système ou supprimez l’identité affectée par l’utilisateur.

Quand vous désactivez l’identité managée sur votre ressource d’application logique, vous supprimez la capacité de cette identité à demander l’accès aux ressources Azure auxquelles elle avait accès.

Notes

Si vous désactivez l’identité affectée par le système, toutes les connexions utilisées par les workflows dans le workflow de cette application logique ne fonctionnent pas au moment de l’exécution, même si vous réactivez immédiatement l’identité. Ce comportement se produit car la désactivation de l’identité entraîne la suppression de l’ID d’objet. Chaque fois que vous activez l’identité, Azure génère l’identité avec un ID d’objet différent et unique. Pour résoudre ce problème, vous devez recréer les connexions afin qu’elles utilisent l’ID d’objet actuel pour l’identité affectée par le système actuelle.

Essayez autant que possible de ne pas désactiver l’identité affectée par le système. Si vous souhaitez supprimer l’accès de l’identité aux ressources Azure, supprimez l’attribution de rôle de l’identité de la ressource cible. Si vous supprimez votre ressource d’application logique, Azure supprime automatiquement l’identité managée de Microsoft Entra ID.

Les étapes décrites dans cette section traitent de l’utilisation du portail Azure et du modèle ARM (Azure Resource Manager). Pour Azure PowerShell, Azure CLI et l’API REST Azure, consultez la documentation suivante :

Outil Documentation
Azure PowerShell 1. Supprimer une attribution de rôle
2. Supprimer une identité affectée par l’utilisateur
Azure CLI 1. Supprimer une attribution de rôle
2. Supprimer une identité affectée par l’utilisateur
API REST Azure 1. Supprimer une attribution de rôle
2. Supprimer une identité affectée par l’utilisateur

Désactiver l’identité managée dans le portail Azure

Pour supprimer l’accès pour l’identité managée, supprimez l’attribution de rôle de l’identité de la ressource cible, puis désactivez l’identité managée.

Supprimer une attribution de rôle

Les étapes suivantes permettent de supprimer l’accès à la ressource cible de l’identité managée :

  1. Dans le portail Azure, accédez à la ressource Azure cible dont vous souhaitez supprimer l’accès à l’identité managée.

  2. Dans le menu de la ressource cible, sélectionnez Contrôle d’accès (IAM) . Sous la barre d’outils, sélectionnez Attributions de rôle.

  3. Dans la liste des rôles, sélectionnez les identités managées que vous souhaitez supprimer. Dans la barre d’outils, sélectionnez Supprimer.

    Conseil

    Si l’option Supprimer est désactivée, vous n’avez probablement pas les autorisations appropriées. Pour plus d’informations sur les autorisations qui vous permettent de gérer des rôles pour les ressources, consultez Administration istrator role permissions in Microsoft Entra ID.

Désactiver l’identité managée sur la ressource d’application logique

  1. Dans le portail Azure, ouvrez votre ressource d’application logique.

  2. Dans le menu de navigation de l’application logique, sous Paramètres, sélectionnez Identité, puis suivez les étapes correspondant à votre identité :

    • Sélectionnez Affecté(e) par le système>Actif>Enregistrer. Quand Azure vous invite à confirmer l’opération, sélectionnez Oui.

    • Sélectionnez Affecté(e) par l’utilisateur et l’identité managée, puis sélectionnez Supprimer. Quand Azure vous invite à confirmer l’opération, sélectionnez Oui.

Désactiver l’identité managée dans un modèle ARM

Si vous avez créé l’identité managée de l’application logique à l’aide d’un modèle ARM, définissez la propriété enfant de l’identityobjet type sur None.

"identity": {
   "type": "None"
}

Étapes suivantes