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

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

Dans les workflows d’application logique, certains déclencheurs et actions prennent en charge l’utilisation d’une identité managée pour authentifier l’accès aux ressources protégées par Azure Active Directory (Azure AD). Quand vous utilisez une identité managée pour authentifier votre connexion, vous n’avez pas besoin de fournir d’informations d’identification, de secrets ni de jetons Azure AD. 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 certaines différences entre ces types d’identité :

  • 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.

Cet article explique comment activer et configurer une identité managée pour votre application logique et fournit un exemple d’utilisation de l’identité pour l’authentification. Contrairement à l’identité affectée par le système, que vous n’avez pas besoin de créer manuellement, vous devez créer manuellement l’identité affectée par l’utilisateur. Cet article montre comment créer une identité affectée par l’utilisateur avec le portail Azure et le modèle ARM (Azure Resource Manager). 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é 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 à la fois.

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

Où utiliser une identité managée

Seules les opérations de connecteur intégrées et managées spécifiques qui prennent en charge l’authentification ouverte Azure AD (Azure AD OAuth) peuvent utiliser une identité managée pour l’authentification. Le tableau suivant fournit uniquement une sélection d’exemples. Pour obtenir une liste plus complète, passez en revue Types d’authentification pour les déclencheurs et les actions qui prennent en charge l’authentification et Services Azure qui prennent en charge l’authentification Azure AD avec des identités managées.

Le tableau suivant répertorie les connecteurs qui prennent en charge l’utilisation d’une identité managée dans un flux de travail d’application logique Consommation :

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 AD Identity Protection
- 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
- Machine virtuelle Azure
- HTTP avec Azure AD
- SQL Server

Prérequis

  • Un compte et un abonnement Azure. Si vous n’avez pas encore d’abonnement, vous pouvez vous inscrire pour obtenir un compte Azure gratuitement. L’identité managée et la ressource Azure cible à laquelle vous souhaitez accéder doivent utiliser le même abonnement Azure.

  • Ressource Azure cible à laquelle vous souhaitez accéder. Sur cette ressource, vous allez ajouter le rôle nécessaire à l’identité managée pour accéder à cette ressource au nom de votre application logique ou de la connexion. Pour ajouter des rôles à une identité managée, vous devez disposer d’autorisations d’administrateur Azure AD qui permettent d’attribuer des rôles à des identités dans le locataire Azure AD correspondant.

  • Ressource d’application logique et workflow où vous souhaitez utiliser le déclencheur ou les actions qui prennent en charge les identités managées.

Activer une identité attribuée par le système sur le portail Azure

  1. Dans le portail Azure, accédez à votre ressource d’application logique.

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

  3. Dans le volet Identité, sous Affecté(e) par le système, sélectionnez Activé>Enregistrer. Quand Azure vous invite à confirmer l’opération, sélectionnez Oui.

    Capture d’écran montrant le portail Azure avec le volet « Identité » de l’application logique Consommation et l’onglet « Affecté(e) par le système » avec les options « Activé » et « Enregistrer » sélectionnées.

    Notes

    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 d’Azure AD et est représentée par un ID d’objet.

    Capture d’écran montrant le volet « Identité » de l’application logique Consommation avec l’ID d’objet pour l’identité affectée par le système.

    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 Azure AD.
  4. À présent, suivez les étapes qui donnent à cette identité l’accès à la ressource, et que vous trouverez plus loin dans cette rubrique.

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 Azure AD. 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 Azure AD où l’application logique est maintenant membre. À l’intérieur du locataire Azure AD, 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 Application logique (consommation) ou Application logique (standard), vous devez d’abord créer cette identité en tant que ressource Azure distincte.

  1. Dans la zone de recherche du portail Azure, entrez managed identities. Sélectionnez Identités managées.

    Capture d’écran montrant le portail Azure avec l’option « Identités managées » sélectionnée.

  2. Dans le volet Identités managées, sélectionnez Créer.

    Capture d’écran montrant le volet « Identités managées » avec l’option « Créer » sélectionnée.

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

    Capture d’écran montrant le volet « Créer une identité managée affectée par l’utilisateur » avec les détails de l’identité managée.

    Propriété Obligatoire Valeur Description
    Abonnement Oui <Azure-subscription-name> Nom de l’abonnement Azure à utiliser.
    Groupe de ressources Oui <nom-groupe-de-ressources-Azure> Nom du groupe de ressources Azure à utiliser. 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 le volet Identité, sélectionnez Affecté(e) par l’utilisateur>Ajouter.

    Capture d’écran montrant l’application logique Consommation et le volet « Identité » avec « Ajouter » sélectionné.

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

    1. Dans la liste Abonnement, sélectionnez votre abonnement Azure si cela n’est pas déjà fait.

    2. Dans la liste présentant toutes les identités managées de cet abonnement, sélectionnez l’identité affectée par l’utilisateur qui vous intéresse. 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.

      Capture d’écran montrant l’application logique Consommation et l’identité affectée par l’utilisateur sélectionnée.

    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.

    Capture d’écran montrant l’application logique Consommation et l’association entre l’identité affectée par l’utilisateur et la ressource d’application logique.

  5. À présent, suivez les étapes qui donnent à cette identité l’accès à la ressource, et que vous trouverez plus loin dans cette rubrique.

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 la définition d’une ressource d’application logique pour une requête HTTP PUT, et comprend un objet identity non paramétrable. La réponse à la requête PUT et à l’opération GET qui suit comporte également cet objet identity :

{
   "$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. Cet exemple montre comment l’objet userAssignedIdentities enfant référence une variable userAssignedIdentityName que vous définissez dans la section variables de 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.

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 de la ressource, sélectionnez Contrôle d’accès (IAM)>Ajouter>Ajouter une attribution de rôle.

    Notes

    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 Azure AD.

  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 les rôles de conteneur de stockage spécifiques, passez en revue les Rôles qui peuvent 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 la documentation,Attribution de 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 Attribuer un accès d’identité managée à une autre ressource à l’aide du RBAC Azure.

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.

    Capture d’écran montrant le portail Azure et l’exemple de coffre de clés avec le volet « Stratégies d’accès » ouvert.

  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.

    Capture d’écran montrant l’onglet « Autorisations » avec les autorisations « Liste » sélectionnées.

  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, passez en revue Authentification avec des identités managées.

  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.

    Notes

    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.

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

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

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

        Capture d’écran montrant un exemple d’action intégrée avec la liste « Ajouter un nouveau paramètre » ouverte et l’option « Authentification » sélectionnée dans Consommation.

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

        Capture d’écran montrant un exemple d’action intégrée avec la liste « Type d’authentification » ouverte et l’option « Identité managée » sélectionnée dans Consommation.

      Pour plus d’informations, passez en revue 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 :

        Capture d’écran montrant l’action Azure Resource Manager et l’option « Se connecter avec une identité managée » sélectionnée dans Consommation.

      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 :

          Capture d’écran montrant la page du nom de la connexion avec une seule identité managée sélectionnée dans Consommation.

        • 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 :

          Capture d’écran montrant la page du nom de la connexion avec l’option « Identité managée Logic Apps » sélectionnée dans Consommation.

        Pour plus d’informations, passez en revue Exemple : Authentifier un déclencheur ou une action de 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 les rubriques suivantes :

- 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 :

Capture d’écran montrant le portail Azure avec le workflow d’application logique Consommation et l’action HTTP configurée pour accéder à la ressource.

  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.

    Capture d’écran montrant le workflow Consommation avec l’action HTTP et la liste « Ajouter un nouveau paramètre » ouverte avec la propriété « Authentification » sélectionnée.

    Notes

    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.

    Capture d’écran montrant le workflow Consommation avec l’action HTTP et la propriété « Authentification » avec la valeur « Identité managée » sélectionnée.

  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.

      Capture d’écran montrant le workflow Consommation avec l’action HTTP et la propriété « Identité managée » avec la valeur « Identité managée affectée par le système » sélectionnée.

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

      Capture d’écran montrant le workflow Consommation avec l’action HTTP et la propriété « Identité managée » avec l’identité affectée par l’utilisateur sélectionnée.

    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 Azure Active Directory, 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 Azure AD.

    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.

    Capture d’écran montrant le workflow Consommation avec l’action HTTP et la propriété « Audience » définie sur l’ID de la ressource cible.

    Pour plus d’informations sur l’autorisation de l’accès au Stockage Azure avec Azure AD, 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 Azure AD, sélectionnez Se connecter avec une identité managée.

    Capture d’écran montrant l’action Azure Resource Manager et l’option « Se connecter avec une identité managée » sélectionnée.

  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 étant une action à authentification unique, le volet d’informations de connexion présente une liste Identité managée 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 à authentification multiple, comme le Stockage Blob Azure, le volet d’informations de connexion présente une liste Type d’authentification comprenant notamment l’option Identité managée Logic Apps.

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

    Capture d’écran montrant l’action Azure Resource Manager avec le nom de connexion entré et l’option « Identité managée affectée par le système » sélectionnée.

    Notes

    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 Azure AD 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 Application logique (Consommation) , la configuration de la connexion est enregistrée dans l’objet parameters de la définition de la ressource d’application 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 applications logiques 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 à authentification multiple 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é apiVersion est définie sur 2016-06-01.
  • 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",
    "name": "[variables('connections_azureautomation_name')]",
    "apiVersion": "2016-06-01",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureautomation')]"
        },
        "customParameterValues": {},
        "displayName": "[variables('connections_azureautomation_name')]",
        "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é apiVersion est définie sur 2018-07-01-preview.
  • 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": "2018-07-01-preview",
    "name": "[variables('connections_azureblob_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues":{},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureblob')]"
        },
        "customParameterValues": {},
        "displayName": "[variables('connections_azureblob_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        }
    }
}

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 :

Diagramme conceptuel montrant la première connexion avec authentification entre l’application logique et le magasin de jetons, ainsi qu’une deuxième connexion entre le magasin de jetons et la ressource cible.

  • 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.

    Capture d’écran montrant le portail Azure, la ressource d’application logique Standard, le volet « Connexions » avec « Vue JSON » sélectionné.

  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 d’Azure AD.

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 vous permettant de gérer des rôles pour des ressources, passez en revue Autorisations des rôles d’administrateur dans Azure Active Directory.

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