Toegang en verbindingen met Azure-resources verifiëren met beheerde identiteiten in Azure Logic Apps

  • Artikel

Van toepassing op: Azure Logic Apps (Verbruik + Standard)

Als u wilt voorkomen dat referenties, geheimen of Microsoft Entra-tokens worden opgegeven, opgeslagen en beheerd, kunt u een beheerde identiteit gebruiken om toegang of verbindingen van uw werkstroom voor logische apps te verifiëren bij met Microsoft Entra beveiligde resources. In Azure Logic Apps bieden sommige connectorbewerkingen ondersteuning voor het gebruik van een beheerde identiteit wanneer u de toegang tot resources moet verifiëren die worden beveiligd door Microsoft Entra-id. Azure beheert deze identiteit en helpt verificatiegegevens veilig te houden, zodat u deze gevoelige informatie niet hoeft te beheren. Zie Wat zijn beheerde identiteiten voor Azure-resources? voor meer informatie.

Azure Logic Apps ondersteunt de volgende typen beheerde identiteiten:

In de volgende lijst worden enkele verschillen tussen deze typen beheerde identiteiten beschreven:

  • Een logische app-resource kan slechts één unieke door het systeem toegewezen identiteit inschakelen en gebruiken.

  • Een resource voor logische apps kan dezelfde door de gebruiker toegewezen identiteit delen in een groep andere logische app-resources.

In deze handleiding ziet u hoe u de volgende taken uitvoert:

  • Schakel de door het systeem toegewezen identiteit in en stel deze in voor uw logische app-resource. Deze handleiding bevat een voorbeeld van het gebruik van de identiteit voor verificatie.

  • Een door de gebruiker toegewezen identiteit maken en instellen. Deze handleiding laat zien hoe u deze identiteit maakt met behulp van Azure Portal of een ARM-sjabloon (Azure Resource Manager) en hoe u de identiteit voor verificatie gebruikt. Raadpleeg de volgende documentatie voor Azure PowerShell, Azure CLI en Azure REST API:

Hulpprogramma Documentatie
Azure PowerShell Door de gebruiker toegewezen identiteit maken
Azure-CLI Door de gebruiker toegewezen identiteit maken
Azure REST API Door de gebruiker toegewezen identiteit maken

Vereisten

  • Een Azure-account en -abonnement. Als u nog geen abonnement hebt, meld u dan aan voor een gratis Azure-account. Zowel de beheerde identiteit als de doelresource van Azure waar u toegang nodig hebt, moeten hetzelfde Azure-abonnement gebruiken.

  • De Azure-doelresource waartoe u toegang wilt krijgen. Voor deze resource moet u de benodigde rol voor de beheerde identiteit toevoegen om toegang te krijgen tot die resource namens uw logische app of verbinding. Als u een rol wilt toevoegen aan een beheerde identiteit, hebt u beheerdersmachtigingen van Microsoft Entra nodig waarmee rollen kunnen worden toegewezen aan de identiteiten in de bijbehorende Microsoft Entra-tenant.

  • De resource en werkstroom van de logische app waar u de trigger of acties wilt gebruiken die beheerde identiteiten ondersteunen.

Verschillen tussen beheerde identiteiten tussen verbruiks- en standaardlogica-apps

Op basis van het resourcetype van uw logische app kunt u de door het systeem toegewezen identiteit, door de gebruiker toegewezen identiteit of beide tegelijk inschakelen:

Logische apps Omgeving Ondersteuning voor beheerde identiteit
Verbruik - Multitenant Azure Logic Apps

- Integratieserviceomgeving (ISE)		 - U kunt de door het systeem toegewezen identiteit of de door de gebruiker toegewezen identiteit inschakelen, maar niet beide in uw logische app.

- U kunt de beheerde identiteit gebruiken op resourceniveau van de logische app en op verbindingsniveau.

- Als u de door de gebruiker toegewezen identiteit maakt en inschakelt, kan uw logische app slechts één door de gebruiker toegewezen identiteit tegelijk hebben.
Standaard - Azure Logic Apps met één tenant

- App Service Environment v3 (ASEv3)

- Logic Apps met Azure Arc		 - U kunt zowel de door het systeem toegewezen identiteit inschakelen, die standaard is ingeschakeld als de door de gebruiker toegewezen identiteit tegelijk. U kunt ook meerdere door de gebruiker toegewezen identiteiten toevoegen aan uw logische app. Uw logische app kan echter slechts één beheerde identiteit tegelijk gebruiken.

- U kunt de beheerde identiteit gebruiken op resourceniveau van de logische app en op verbindingsniveau.

Zie Limieten voor beheerde identiteiten voor logische apps voor informatie over limieten voor beheerde identiteiten in Azure Logic Apps. Zie de volgende documentatie voor meer informatie over de resourcetypen en omgevingen van de logische app Verbruik en Standard:

Waar u een beheerde identiteit kunt gebruiken

In Azure Logic Apps kunnen alleen specifieke ingebouwde en beheerde connectorbewerkingen die ondersteuning bieden voor OAuth met Microsoft Entra ID een beheerde identiteit gebruiken voor verificatie. De volgende tabellen bevatten alleen een voorbeeldselectie. Zie de volgende documentatie voor een volledigere lijst:

Voor een werkstroom voor logische verbruiks-apps bevat de volgende tabel voorbeelden van connectors die ondersteuning bieden voor verificatie van beheerde identiteiten:

Type connector Ondersteunde connectors
Ingebouwd - Azure API Management
- Azure-app Services
- Azure Functions
- HTTP
- HTTP + Webhook

Opmerking: HTTP-bewerkingen kunnen verbindingen met Azure Storage-accounts achter Azure-firewalls verifiëren met de door het systeem toegewezen identiteit. HTTP-bewerkingen bieden echter geen ondersteuning voor de door de gebruiker toegewezen identiteit voor het verifiëren van dezelfde verbindingen.
Beheerd - Azure-app Service
- Azure Automation
- Azure Blob Storage
- Azure Container Instance
- Azure Cosmos DB
- Azure Data Explorer
- Azure Data Factory
- Azure Data Lake
- Azure Digital Twins
- Azure Event Grid
- Azure Event Hubs
- Azure IoT Central V2
- Azure Key Vault
-Azure Monitor-logboeken
- Azure-wachtrijen
- Azure Resource Manager
- Azure Service Bus
- Azure Sentinel
- Azure Table Storage
- Azure VM
- SQL Server

Door het systeem toegewezen identiteit inschakelen in Azure Portal

In een resource van de logische app Verbruik moet u de door het systeem toegewezen identiteit handmatig inschakelen.

  1. Open uw resource voor de logische app Verbruik in Azure Portal.

  2. Selecteer Identiteit in het menu van de logische app, onder Instellingen.

  3. Selecteer op de pagina Identiteit, onder Systeem toegewezen, de optie Opslaan>. Wanneer u wordt gevraagd om te bevestigen, selecteert u Ja.

    Schermopname van de Azure-portal, de logische app Verbruik, de pagina Identiteit en het tabblad Door het systeem toegewezen, met de geselecteerde opties Aan en Opslaan.

    Notitie

    Als u een foutbericht krijgt dat u slechts één beheerde identiteit kunt hebben, is uw logische app-resource al gekoppeld aan de door de gebruiker toegewezen identiteit. Voordat u de door het systeem toegewezen identiteit kunt toevoegen, moet u eerst de door de gebruiker toegewezen identiteit uit uw logische app-resource verwijderen.

    Uw logische app-resource kan nu de door het systeem toegewezen identiteit gebruiken. Deze identiteit wordt geregistreerd bij Microsoft Entra-id en wordt vertegenwoordigd door een object-id.

    Schermopname van de logische app Verbruik, de pagina Identiteit en de object-id voor door het systeem toegewezen identiteit.

    Eigenschappen Weergegeven als Beschrijving
    Object-id (principal) <identity-resource-ID> Een GUID (Globally Unique Identifier) die de door het systeem toegewezen identiteit vertegenwoordigt voor uw logische app in een Microsoft Entra-tenant.

  4. Volg nu de stappen die de door het systeem toegewezen identiteit toegang geven tot de resource verderop in deze handleiding.

Door het systeem toegewezen identiteit inschakelen in een ARM-sjabloon

Als u het maken en implementeren van logische app-resources wilt automatiseren, kunt u een ARM-sjabloon gebruiken. Als u de door het systeem toegewezen identiteit voor uw logische app-resource in de sjabloon wilt inschakelen, voegt u het identiteitsobject en de onderliggende eigenschap van het type toe aan de resourcedefinitie van de logische app in de sjabloon, bijvoorbeeld:

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

Wanneer Azure de resourcedefinitie van uw logische app maakt, krijgt het identiteitsobject de volgende andere eigenschappen:

"identity": {
   "type": "SystemAssigned",
   "principalId": "<principal-ID>",
   "tenantId": "<Entra-tenant-ID>"
}
Eigenschap (JSON) Weergegeven als Beschrijving
principalId <principal-id> De GUID (Globally Unique Identifier) van het service-principal-object voor de beheerde identiteit die uw logische app vertegenwoordigt in de Microsoft Entra-tenant. Deze GUID wordt soms weergegeven als een object-id of object-id.
tenantId <Microsoft-Entra-ID-tenant-ID> De GUID (Globally Unique Identifier) die de Microsoft Entra-tenant vertegenwoordigt waar de logische app nu lid is. Binnen de Microsoft Entra-tenant heeft de service-principal dezelfde naam als het exemplaar van de logische app.

Door de gebruiker toegewezen identiteit maken in Azure Portal

Voordat u de door de gebruiker toegewezen identiteit kunt inschakelen voor een resource van een logische app voor verbruik of een standaardresource voor logische apps, moet u die identiteit maken als een afzonderlijke Azure-resource.

  1. Voer in het zoekvak van Azure Portal beheerde identiteiten in. Selecteer Beheerde identiteiten in de lijst met resultaten.

    Schermopname van Azure Portal met de geselecteerde optie Beheerde identiteiten.

  2. Selecteer Maken op de werkbalk van de pagina Beheerde identiteiten.

  3. Geef informatie op over uw beheerde identiteit en selecteer Beoordelen en maken, bijvoorbeeld:

    Schermopname van de pagina Create User Assigned Managed Identity, met beheerde identiteitsgegevens.

    Eigenschappen Vereist Weergegeven als Beschrijving
    Abonnement Ja <Azure-abonnementnaam> De naam van het Azure-abonnement
    Resourcegroep Ja <Naam-Azure-resourcegroep> De naam van de Azure-resourcegroep. Maak een nieuwe groep of selecteer een bestaande groep. In dit voorbeeld wordt een nieuwe groep gemaakt met de naam fabrikam-managed-identities-RG.
    Regio Ja <Azure-regio> De Azure-regio waar u informatie over uw resource opslaat. In dit voorbeeld wordt US - west gebruikt.
    Naam Ja <door de gebruiker toegewezen identiteit-naam> De naam om uw door de gebruiker toegewezen identiteit te geven. In dit voorbeeld wordt Fabrikam-user-assigned-identity gebruikt.

    Nadat Azure de informatie heeft gevalideerd, maakt Azure uw beheerde identiteit. U kunt nu de door de gebruiker toegewezen identiteit toevoegen aan uw logische app-resource.

Door de gebruiker toegewezen identiteit toevoegen aan logische app in Azure Portal

  1. Open uw resource voor de logische app Verbruik in Azure Portal.

  2. Selecteer Identiteit in het menu van de logische app, onder Instellingen.

  3. Selecteer op de pagina Identiteit de optie Gebruiker toegewezen en selecteer vervolgens Toevoegen.

    Schermopname van de pagina Verbruikslogica en identiteit met de geselecteerde optie voor Toevoegen.

  4. Voer in het deelvenster Door de gebruiker toegewezen beheerde identiteit toevoegen de volgende stappen uit:

    1. Selecteer uw Azure-abonnement in de lijst Een abonnement selecteren.

    2. Selecteer in de lijst met alle beheerde identiteiten in uw abonnement de door de gebruiker toegewezen identiteit die u wilt. Als u de lijst wilt filteren, voert u in het zoekvak Door de gebruiker toegewezen beheerde identiteiten de naam in voor de identiteit of resourcegroep.

      Schermopname van de logische app Verbruik en de geselecteerde door de gebruiker toegewezen identiteit.

    3. Wanneer u klaar bent, selecteert u Toevoegen.

      Notitie

      Als u een foutmelding krijgt dat u slechts één beheerde identiteit kunt hebben, is uw logische app al gekoppeld aan de door het systeem toegewezen identiteit. Voordat u de door de gebruiker toegewezen identiteit kunt toevoegen, moet u eerst de door het systeem toegewezen identiteit uitschakelen.

    Uw logische app is nu gekoppeld aan de door de gebruiker toegewezen identiteit.

    Schermopname van de logische verbruiks-app met gekoppelde door de gebruiker toegewezen identiteit.

  5. Volg nu de stappen die de identiteit toegang geven tot de resource verderop in deze handleiding.

Door de gebruiker toegewezen identiteit maken in een ARM-sjabloon

Als u het maken en implementeren van logische app-resources wilt automatiseren, kunt u een ARM-sjabloon gebruiken. Deze sjablonen ondersteunen door de gebruiker toegewezen identiteiten voor verificatie.

In de sectie Resources van uw sjabloon zijn voor de resourcedefinitie van uw logische app de volgende items vereist:

  • Een identiteitsobject met de eigenschap Type ingesteld op UserAssigned

  • Een onderliggend object userAssignedIdentities dat de door de gebruiker toegewezen resource en naam aangeeft

In dit voorbeeld ziet u een resource en werkstroomdefinitie voor een HTTP PUT-aanvraag met een niet-geparameteriseerd identiteitsobject . Het antwoord op de PUT-aanvraag en de volgende GET-bewerking bevat ook dit identiteitsobject :

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

Als uw sjabloon ook de resourcedefinitie van de beheerde identiteit bevat, kunt u het identiteitsobject parameteriseren. In het volgende voorbeeld ziet u hoe het onderliggende object userAssignedIdentities verwijst naar een userAssignedIdentityName-variabele die u definieert in de sectie variabelen van uw sjabloon. Deze variabele verwijst naar de resource-id voor uw door de gebruiker toegewezen identiteit.

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

Identiteitstoegang verlenen tot resources

Voordat u de beheerde identiteit van uw logische app voor verificatie kunt gebruiken, moet u toegang instellen voor de identiteit in de Azure-doelresource waarin u de identiteit wilt gebruiken. De manier waarop u toegang instelt, varieert op basis van de doelresource.

Notitie

Wanneer een beheerde identiteit toegang heeft tot een Azure-resource in hetzelfde abonnement, heeft de identiteit alleen toegang tot die resource. In sommige triggers en acties die beheerde identiteiten ondersteunen, moet u echter eerst de Azure-resourcegroep selecteren die de doelresource bevat. Als de identiteit geen toegang heeft op het niveau van de resourcegroep, worden er geen resources in die groep vermeld, ondanks dat ze toegang hebben tot de doelresource.

Als u dit gedrag wilt afhandelen, moet u ook de identiteit toegang geven tot de resourcegroep, niet alleen de resource. Als u uw abonnement moet selecteren voordat u de doelresource kunt selecteren, moet u de identiteit toegang geven tot het abonnement.

In sommige gevallen hebt u mogelijk de identiteit nodig om toegang te krijgen tot de bijbehorende resource. Stel dat u een beheerde identiteit hebt voor een logische app die toegang nodig heeft om de toepassingsinstellingen voor diezelfde logische app bij te werken vanuit een werkstroom. U moet die identiteit toegang geven tot de bijbehorende logische app.

Als u bijvoorbeeld toegang wilt krijgen tot een Azure Blob Storage-account met uw beheerde identiteit, moet u toegang instellen met behulp van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) en de juiste rol voor die identiteit toewijzen aan het opslagaccount. In de stappen in deze sectie wordt beschreven hoe u deze taak kunt voltooien met behulp van de Azure-portal en de Azure Resource Manager-sjabloon (ARM-sjabloon). Raadpleeg de volgende documentatie voor Azure PowerShell, Azure CLI en Azure REST API:

Hulpprogramma Documentatie
Azure PowerShell Roltoewijzing toevoegen
Azure-CLI Roltoewijzing toevoegen
Azure REST API Roltoewijzing toevoegen

Als u echter toegang wilt krijgen tot een Azure-sleutelkluis met uw beheerde identiteit, moet u een toegangsbeleid maken voor die identiteit in uw sleutelkluis en de juiste machtigingen toewijzen voor die identiteit voor die sleutelkluis. In de latere stappen in deze sectie wordt beschreven hoe u deze taak kunt voltooien met behulp van Azure Portal. Raadpleeg de volgende documentatie voor Resource Manager-sjablonen, PowerShell en Azure CLI:

Hulpprogramma Documentatie
Azure Resource Manager-sjabloon (ARM-sjabloon) Resourcedefinitie voor Key Vault-toegangsbeleid
Azure PowerShell Een Key Vault-toegangsbeleid toewijzen
Azure-CLI Een Key Vault-toegangsbeleid toewijzen

Toegang op basis van rollen toewijzen aan een beheerde identiteit met behulp van Azure Portal

Als u een beheerde identiteit wilt gebruiken voor verificatie, moeten sommige Azure-resources, zoals Azure-opslagaccounts, die identiteit toewijzen aan een rol met de juiste machtigingen voor de doelresource. Voor andere Azure-resources, zoals Azure-sleutelkluizen, moet u een toegangsbeleid maken met de juiste machtigingen voor de doelresource voor die identiteit.

  1. Open in Azure Portal de resource waarin u de identiteit wilt gebruiken.

  2. Selecteer in het resourcemenu de optie Toegangsbeheer (IAM)>Roltoewijzing toevoegen.>

    Notitie

    Als de optie Roltoewijzing toevoegen is uitgeschakeld, hebt u geen machtigingen om rollen toe te wijzen. Zie Ingebouwde rollen in Microsoft Entra voor meer informatie.

  3. Wijs de benodigde rol toe aan uw beheerde identiteit. Wijs op het tabblad Rol een rol toe die uw identiteit de vereiste toegang geeft tot de huidige resource.

    Wijs voor dit voorbeeld de rol toe met de naam Storage Blob Data Contributor, waaronder schrijftoegang voor blobs in een Azure Storage-container. Zie Rollen die toegang hebben tot blobs in een Azure Storage-container voor meer informatie over specifieke opslagcontainerrollen.

  4. Kies vervolgens de beheerde identiteit waaraan u de rol wilt toewijzen. Selecteer onder Toegang toewijzen de optie Leden toevoegen aan beheerde identiteit>.

  5. Selecteer of geef op basis van het type van uw beheerde identiteit de volgende waarden op:

    Type Azure-service-exemplaar Abonnement Lid
    Door systeem toegewezen Logische app <Azure-abonnementnaam> <naam-van-uw-logische-app>
    Door gebruiker toegewezen Niet van toepassing <Azure-abonnementnaam> <uw door de gebruiker toegewezen identiteit-naam>

    Zie Rollen toewijzen met behulp van Azure Portal voor meer informatie over het toewijzen van rollen.

Nadat u klaar bent, kunt u de identiteit gebruiken om toegang te verifiëren voor triggers en acties die beheerde identiteiten ondersteunen.

Zie Een beheerde identiteit toegang tot een andere resource toewijzen met behulp van Azure RBAC voor meer algemene informatie over deze taak.

Een toegangsbeleid maken met behulp van Azure Portal

Als u een beheerde identiteit wilt gebruiken voor verificatie, moeten sommige Azure-resources, zoals Azure-sleutelkluizen, een toegangsbeleid maken met de juiste machtigingen voor de doelresource voor die identiteit. Voor andere Azure-resources, zoals Azure-opslagaccounts, moet u die identiteit toewijzen aan een rol met de juiste machtigingen voor de doelresource.

  1. Open in Azure Portal de doelresource waarin u de identiteit wilt gebruiken. In dit voorbeeld wordt een Azure-sleutelkluis gebruikt als doelresource.

  2. Selecteer in het resourcemenu Access-beleid>maken. Hiermee opent u het deelvenster Een toegangsbeleid maken.

    Notitie

    Als de resource niet beschikt over de optie Toegangsbeleid , kunt u in plaats daarvan een roltoewijzing toewijzen.

    Schermopname van azure Portal en key vault-voorbeeld met het geopende deelvenster Access-beleid.

  3. Selecteer op het tabblad Machtigingen de vereiste machtigingen die de identiteit nodig heeft voor toegang tot de doelresource.

    Als u bijvoorbeeld de identiteit wilt gebruiken met de bewerking Lijstgeheimen van de door Azure Key Vault beheerde connector, moet de identiteit lijstmachtigingen hebben. Selecteer in de kolom Geheime machtigingen de optie Lijst.

    Schermopname van het tabblad Machtigingen met geselecteerde lijstmachtigingen.

  4. Wanneer u klaar bent, selecteert u Volgende. Zoek en selecteer op het tabblad Principal de beheerde identiteit, een door de gebruiker toegewezen identiteit in dit voorbeeld.

  5. Sla de optionele toepassingsstap over, selecteer Volgende en voltooi het maken van het toegangsbeleid.

In de volgende sectie ziet u hoe u een beheerde identiteit gebruikt met een trigger of actie om toegang te verifiëren. Het voorbeeld gaat verder met de stappen uit een eerdere sectie waarin u toegang instelt voor een beheerde identiteit met behulp van RBAC en azure Key Vault niet als voorbeeld gebruikt. De algemene stappen voor het gebruik van een beheerde identiteit voor verificatie zijn echter hetzelfde.

Toegang verifiëren met beheerde identiteit

Nadat u de beheerde identiteit voor uw logische app-resource hebt ingeschakeld en die identiteit toegang hebt tot de Azure-doelresource of -service, kunt u die identiteit gebruiken in triggers en acties die beheerde identiteiten ondersteunen.

Belangrijk

Als u een Azure-functie hebt waarin u de door het systeem toegewezen identiteit wilt gebruiken, schakelt u eerst verificatie in voor Azure Functions.

De volgende stappen laten zien hoe u de beheerde identiteit gebruikt met een trigger of actie met behulp van Azure Portal. Zie Verificatie van beheerde identiteiten om de beheerde identiteit op te geven in de onderliggende JSON-definitie van een trigger of actie.

  1. Open uw resource voor de logische app Verbruik in Azure Portal.

  2. Als u dit nog niet hebt gedaan, voegt u de trigger of actie toe die beheerde identiteiten ondersteunt.

    Notitie

    Niet alle connectorbewerkingen bieden ondersteuning voor het toevoegen van een verificatietype. Zie Verificatietypen voor triggers en acties die ondersteuning bieden voor verificatie voor meer informatie.

  3. Voer de volgende stappen uit op de trigger of actie die u hebt toegevoegd:

    • Ingebouwde connectorbewerkingen die ondersteuning bieden voor verificatie van beheerde identiteiten

      Deze stappen worden voortgezet door de HTTP-actie als voorbeeld te gebruiken.

      1. Voeg in de lijst Geavanceerde parameters de eigenschap Verificatie toe als de eigenschap nog niet wordt weergegeven.

        Schermopname van de werkstroom Verbruik met ingebouwde actie en geopende lijst met de naam Geavanceerde parameters, met de geselecteerde optie voor verificatie.

        Nu worden zowel de eigenschap Verificatie als de lijst met verificatietypen weergegeven in de actie.

        Schermopname van de sectie Geavanceerde parameters met toegevoegde verificatie-eigenschap en lijst met verificatietypen.

      2. Selecteer Beheerde identiteit in de lijst Verificatietype.

        Schermopname van de werkstroom Verbruik met ingebouwde actie, lijst met geopend verificatietype en geselecteerde optie voor beheerde identiteit.

        In de sectie Verificatie ziet u nu de volgende opties:

        • Een lijst met beheerde identiteiten waaruit u een specifieke beheerde identiteit kunt selecteren

        • De eigenschap Doelgroep wordt weergegeven op specifieke triggers en acties, zodat u de resource-id voor de Azure-doelresource of -service kunt instellen. Anders gebruikt de eigenschap Doelgroep standaard de https://management.azure.com/ resource-id. Dit is de resource-id voor Azure Resource Manager.

      3. Selecteer in de lijst beheerde identiteit de identiteit die u wilt gebruiken, bijvoorbeeld:

        Schermopname van de sectie Verificatie met de lijst Verificatietype en de eigenschap Doelgroep.

        Notitie

        De standaard geselecteerde optie is de door het systeem toegewezen beheerde identiteit, zelfs als u geen beheerde identiteiten hebt ingeschakeld.

        Als u een beheerde identiteit wilt gebruiken, moet u die identiteit eerst inschakelen in uw logische app. In een logische app Verbruik kunt u de door het systeem toegewezen of door de gebruiker toegewezen beheerde identiteit hebben, maar niet beide.

      Zie Voorbeeld: Ingebouwde trigger of actie verifiëren met een beheerde identiteit voor meer informatie.

    • Beheerde connectorbewerkingen die ondersteuning bieden voor verificatie van beheerde identiteiten

      1. Selecteer in het deelvenster Verbinding maken ion maken in de lijst Verificatie de optie Beheerde identiteit, bijvoorbeeld:

        Schermopname van de werkstroom Verbruik met de actie Azure Resource Manager en de geselecteerde optie voor Beheerde identiteit.

      2. Geef in het volgende deelvenster voor Verbinding maken ionnaam een naam op die moet worden gebruikt voor de verbinding.

      3. Kies voor het verificatietype een van de volgende opties op basis van uw beheerde connector:

        • Eén verificatie: deze connectors ondersteunen slechts één verificatietype. Dit is de beheerde identiteit in dit geval.

          1. Selecteer in de lijst beheerde identiteit de momenteel ingeschakelde beheerde identiteit.

          2. Wanneer u klaar bent, selecteert u Nieuwe maken.

        • Meervoudige verificatie: deze connectors ondersteunen meerdere verificatietypen, maar u kunt slechts één type tegelijk selecteren en gebruiken.

          Deze stappen worden voortgezet met behulp van een Azure Blob Storage-actie als voorbeeld.

          1. Selecteer in de lijst Verificatietype de beheerde identiteit van Logic Apps.

            Schermopname van het vak Verbruikswerkstroom, het maken van verbindingen en de geselecteerde optie voor beheerde identiteit van Logic Apps.

          2. Wanneer u klaar bent, selecteert u Nieuwe maken.

        Zie Voorbeeld: Trigger of actie van beheerde connector verifiëren met een beheerde identiteit voor meer informatie.

Voorbeeld: Ingebouwde trigger of actie verifiëren met een beheerde identiteit

De ingebouwde HTTP-trigger of -actie kan de door het systeem toegewezen identiteit gebruiken die u inschakelt voor uw logische app-resource. Over het algemeen gebruikt de HTTP-trigger of -actie de volgende eigenschappen om de resource of entiteit op te geven die u wilt openen:

Eigenschappen Vereist Beschrijving
Methode Ja De HTTP-methode die wordt gebruikt door de bewerking die u wilt uitvoeren
URI Ja De eindpunt-URL voor toegang tot de Azure-doelresource of -entiteit. De URI-syntaxis bevat meestal de resource-id voor de Azure-doelresource of -service.
Kopteksten Nee Koptekstwaarden die u nodig hebt of die u wilt opnemen in de uitgaande aanvraag, zoals het inhoudstype
Query's Nee Queryparameters die u nodig hebt of die u wilt opnemen in de aanvraag. Voer bijvoorbeeld queryparameters uit voor een specifieke bewerking of voor de API-versie van de bewerking die u wilt uitvoeren.
Verificatie Ja Het verificatietype dat moet worden gebruikt voor het verifiëren van toegang tot de Azure-doelresource of -service

Stel dat u de bewerking Momentopnameblob wilt uitvoeren op een blob in het Azure Storage-account waar u eerder toegang voor uw identiteit hebt ingesteld. De Azure Blob Storage-connector biedt momenteel deze bewerking echter niet. In plaats daarvan kunt u deze bewerking uitvoeren met behulp van de HTTP-actie of een andere BLob Service REST API-bewerking.

Belangrijk

Als u toegang wilt krijgen tot Azure-opslagaccounts achter firewalls met behulp van de Azure Blob Storage-connector en beheerde identiteiten, moet u ook uw opslagaccount instellen met de uitzondering die toegang toestaat door vertrouwde Microsoft-services.

Als u de bewerking Momentopnameblob wilt uitvoeren, geeft de HTTP-actie de volgende eigenschappen op:

Eigenschappen Vereist Voorbeeldwaarde Beschrijving
URI Ja https://<storage-account-name>/<folder-name>/{name} De resource-id voor een Azure Blob Storage-bestand in de Azure Global (openbare) omgeving, die gebruikmaakt van deze syntaxis
Methode Ja PUT De HTTP-methode die door de momentopnameblobbewerking wordt gebruikt
Kopteksten Voor Azure Storage x-ms-blob-type = BlockBlob

x-ms-version = 2024-05-05

x-ms-date = formatDateTime(utcNow(),'r')		 De x-ms-blob-typewaarden voor , x-ms-versionen x-ms-date headers zijn vereist voor Azure Storage-bewerkingen.

Belangrijk: Bij uitgaande HTTP-trigger- en actieaanvragen voor Azure Storage vereist de header de x-ms-version eigenschap en de API-versie voor de bewerking die u wilt uitvoeren. De x-ms-date datum moet de huidige datum zijn. Anders mislukt uw werkstroom met een 403 FORBIDDEN fout. Als u de huidige datum in de vereiste notatie wilt ophalen, kunt u de expressie in de voorbeeldwaarde gebruiken.

Zie de volgende documentatie voor meer informatie:

- Aanvraagheaders - Momentopname-blob
- Versiebeheer voor Azure Storage-services
Query's Alleen voor de momentopname-blobbewerking comp = snapshot De naam en waarde van de queryparameter voor de bewerking.

  1. Voeg in de werkstroomontwerper een gewenste trigger toe en voeg vervolgens de HTTP-actie toe.

    In het volgende voorbeeld ziet u een HTTP-voorbeeldactie met alle eerder beschreven eigenschapswaarden die moeten worden gebruikt voor de momentopnameblobbewerking:

    Schermopname van de Azure-portal, de werkstroom Verbruik en de HTTP-actie die is ingesteld voor toegang tot resources.

  2. Voeg in de HTTP-actie de verificatie-eigenschap toe. Selecteer Verificatie in de lijst Geavanceerde parameters.

    Schermopname van de werkstroom Verbruik met de HTTP-actie en de lijst met geavanceerde parameters geopend met de geselecteerde eigenschap Authentication.

    De sectie Verificatie wordt nu weergegeven in uw HTTP-actie .

    Notitie

    Niet alle triggers en acties ondersteunen het toevoegen van een verificatietype. Zie Verificatietypen voor triggers en acties die ondersteuning bieden voor verificatie voor meer informatie.

  3. Selecteer Beheerde identiteit in de lijst Verificatietype.

    Schermopname van de eigenschap Verbruikswerkstroom, HTTP-actie en verificatietype met de geselecteerde optie voor beheerde identiteit.

  4. Selecteer in de lijst beheerde identiteit de beschikbare opties op basis van uw scenario.

    • Als u de door het systeem toegewezen identiteit instelt, selecteert u Door het systeem toegewezen beheerde identiteit.

      Schermopname van de eigenschap Consumption workflow, HTTP action en Managed Identity met de geselecteerde optie voor door het systeem toegewezen beheerde identiteit.

    • Als u de door de gebruiker toegewezen identiteit instelt, selecteert u die identiteit.

      Schermopname van de eigenschap Verbruikswerkstroom, HTTP-actie en Beheerde identiteit met geselecteerde door de gebruiker toegewezen identiteit.

    In dit voorbeeld wordt de door het systeem toegewezen beheerde identiteit voortgezet.

  5. Bij sommige triggers en acties wordt de eigenschap Doelgroep weergegeven, zodat u de resource-id voor de Azure-doelresource of -service kunt instellen.

    Als u bijvoorbeeld de toegang tot een Key Vault-resource in de globale Azure-cloud wilt verifiëren, moet u de eigenschap Doelgroep instellen op precies de volgende resource-id : https://vault.azure.net

    Als u de eigenschap Doelgroep niet instelt, gebruikt de eigenschap Doelgroep standaard de https://management.azure.com/ resource-id. Dit is de resource-id voor Azure Resource Manager.

    Belangrijk

    Zorg ervoor dat de doelresource-id exact overeenkomt met de waarde die microsoft Entra-id verwacht. Anders krijgt u mogelijk een 400 Bad Request fout of een 401 Unauthorized fout. Als de resource-id slashes bevat, moet u deze dus opnemen. Neem ze anders niet op.

    Voor de resource-id voor alle Azure Blob Storage-accounts is bijvoorbeeld een afsluitende slash vereist. Voor de resource-id voor een specifiek opslagaccount is echter geen afsluitende slash vereist. Controleer de resource-id's voor de Azure-services die Ondersteuning bieden voor Microsoft Entra-id.

    In dit voorbeeld wordt de eigenschap https://storage.azure.com/ Doelgroep zodanig ingesteld dat de toegangstokens die worden gebruikt voor verificatie geldig zijn voor alle opslagaccounts. U kunt echter ook de URL van de hoofdservice opgeven voor https://<your-storage-account>.blob.core.windows.neteen specifiek opslagaccount.

    Schermopname van de werkstroom Verbruik en de HTTP-actie, waarbij de eigenschap Doelgroep is ingesteld op de doelresource-id.

    Zie de volgende documentatie voor meer informatie over het autoriseren van toegang met Microsoft Entra ID voor Azure Storage:

  6. Ga door met het bouwen van de werkstroom zoals u wilt.

Voorbeeld: Trigger of actie van beheerde connector verifiëren met een beheerde identiteit

De beheerde Azure Resource Manager-connector heeft een actie met de naam Een resource lezen, die de beheerde identiteit kan gebruiken die u inschakelt voor uw logische app-resource. In dit voorbeeld ziet u hoe u de door het systeem toegewezen beheerde identiteit gebruikt met een beheerde connector.

  1. Voeg in de werkstroomontwerper de Actie Azure Resource Manager met de naam Een resource lezen toe.

  2. Selecteer in het deelvenster Verbinding maken ion maken in de lijst Verificatie de optie Beheerde identiteit en selecteer vervolgens Aanmelden.

    Notitie

    In andere connectors wordt in de lijst Verificatietype de beheerde identiteit van Logic Apps weergegeven. Selecteer daarom deze optie.

    Schermopname van de werkstroom Verbruik, de actie Azure Resource Manager, de lijst met geopende verificatie en de geselecteerde optie voor beheerde identiteit.

  3. Geef een naam op voor de verbinding en selecteer de beheerde identiteit die u wilt gebruiken.

    Als u de door het systeem toegewezen identiteit hebt ingeschakeld, selecteert de lijst met beheerde identiteiten automatisch door het systeem toegewezen beheerde identiteit. Als u in plaats daarvan een door de gebruiker toegewezen identiteit hebt ingeschakeld, selecteert de lijst automatisch de door de gebruiker toegewezen identiteit.

    In dit voorbeeld is door het systeem toegewezen beheerde identiteit de enige beschikbare selectie.

    Schermopname van de actie Verbruikswerkstroom en Azure Resource Manager met de ingevoerde verbindingsnaam en de geselecteerde optie voor door het systeem toegewezen beheerde identiteit.

    Notitie

    Als de beheerde identiteit niet is ingeschakeld wanneer u de verbinding probeert te maken of wijzigen, of als de beheerde identiteit is verwijderd terwijl er nog steeds een verbinding met een beheerde identiteit bestaat, krijgt u een foutbericht met de mededeling dat u de identiteit moet inschakelen en toegang moet verlenen tot de doelresource.

  4. Wanneer u klaar bent, selecteert u Nieuwe maken.

  5. Nadat de ontwerper de verbinding heeft gemaakt, kan de ontwerper dynamische waarden, inhoud of schema ophalen met behulp van verificatie van beheerde identiteiten.

  6. Ga door met het bouwen van de werkstroom zoals u wilt.

Resourcedefinities en verbindingen van logische apps die gebruikmaken van een beheerde identiteit

Een verbinding die een beheerde identiteit inschakelt en gebruikt, is een speciaal verbindingstype dat alleen werkt met een beheerde identiteit. Tijdens runtime gebruikt de verbinding de beheerde identiteit die is ingeschakeld voor de resource van de logische app. Azure Logic Apps controleert of bewerkingen van een beheerde connector in de werkstroom zijn ingesteld voor het gebruik van de beheerde identiteit en of alle vereiste machtigingen bestaan om de beheerde identiteit te gebruiken voor toegang tot de doelresources die zijn opgegeven door de connectorbewerkingen. Als deze controle is geslaagd, haalt Azure Logic Apps het Microsoft Entra-token op dat is gekoppeld aan de beheerde identiteit, gebruikt deze identiteit om de toegang tot de Azure-doelresource te verifiëren en worden de geconfigureerde bewerkingen in de werkstroom uitgevoerd.

In een resource van de logische app Verbruik wordt de verbindingsconfiguratie opgeslagen in het object van parameters de resourcedefinitie, dat het $connections object bevat dat verwijst naar de resource-id van de verbinding, samen met de resource-id van de beheerde identiteit wanneer de door de gebruiker toegewezen identiteit is ingeschakeld.

In dit voorbeeld ziet u de parameters objectconfiguratie wanneer de logische app de door het systeem toegewezen identiteit inschakelt:

"parameters": {
   "$connections": {
      "value": {
         "<action-name>": {
            "connectionId": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>",
            "connectionName": "<connector-name>",
            "connectionProperties": {
               "authentication": {
                  "type": "ManagedServiceIdentity"
               }
            },
            "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<managed-connector-type>"
         }
      }
   }
}

In dit voorbeeld ziet u de parameters objectconfiguratie wanneer de logische app de door de gebruiker toegewezen beheerde identiteit inschakelt:

"parameters": {
   "$connections": {
      "value": {
         "<action-name>": {
            "connectionId": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>",
            "connectionName": "<connector-name>",
            "connectionProperties": {
               "authentication": {
                  "type": "ManagedServiceIdentity",
                  "identity": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/microsoft.managedidentity/userassignedidentities/<managed-identity-name>"
               }
            },
            "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/<managed-connector-type>"
         }
      }
   }
}

ARM-sjabloon voor API-verbindingen en beheerde identiteiten

Als u een ARM-sjabloon gebruikt om de implementatie te automatiseren en uw werkstroom een API-verbinding bevat, die wordt gemaakt door een beheerde connector die gebruikmaakt van een beheerde identiteit, moet u een extra stap uitvoeren.

In een ARM-sjabloon verschilt de resourcedefinitie van de onderliggende connector op basis van of u een resource voor de logische app Verbruik of Standard hebt en of de connector opties voor één verificatie of meervoudige verificatie weergeeft.

De volgende voorbeelden zijn van toepassing op resources van logische apps voor verbruik en laten zien hoe de onderliggende connectorresourcedefinitie verschilt tussen een connector met één verificatie en een connector voor meerdere verificaties.

Eenmalige verificatie

In dit voorbeeld ziet u de onderliggende verbindingsresourcedefinitie voor een connectoractie die slechts één verificatietype ondersteunt en een beheerde identiteit gebruikt in een werkstroom voor logische verbruiks-apps, waarbij de definitie de volgende kenmerken bevat:

  • De kind eigenschap is ingesteld V1 op voor een logische app Verbruik.

  • De eigenschap parameterValueType is ingesteld op Alternative.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_<connector-name>_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_<connector-name>_name')]",
        "parameterValueSet": {},
        "parameterValueType": "Alternative"
    }
},

Meervoudige verificatie

In dit voorbeeld ziet u de onderliggende verbindingsresourcedefinitie voor een connectoractie die ondersteuning biedt voor meerdere verificatietypen en een beheerde identiteit gebruikt in een werkstroom voor logische verbruiks-apps, waarbij de definitie de volgende kenmerken bevat:

  • De kind eigenschap is ingesteld V1 op voor een logische app Verbruik.

  • Het parameterValueSet object bevat een name eigenschap die is ingesteld op managedIdentityAuth en een values eigenschap die is ingesteld op een leeg object.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_<connector-name>_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_<connector-name>_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        },
        "parameterValueType": "Alternative"
    }
}

Geavanceerde controle instellen over API-verbindingsverificatie

Wanneer uw standaardwerkstroom voor logische apps gebruikmaakt van een API-verbinding, die wordt gemaakt door een beheerde connector, communiceert Azure Logic Apps met de doelresource, zoals uw e-mailaccount, sleutelkluis, enzovoort, met behulp van twee verbindingen:

Conceptueel diagram toont eerste verbinding met verificatie tussen logische app en tokenarchief plus tweede verbinding tussen tokenarchief en doelresource.

  • Verbinding maken ion #1 is ingesteld met verificatie voor het interne tokenarchief.

  • Verbinding maken ion #2 is ingesteld met verificatie voor de doelresource.

Wanneer een werkstroom van een logische app verbruik echter een API-verbinding gebruikt, wordt verbinding #1 van u geabstraheerd zonder configuratieopties. Met de resource van de standaard logische app hebt u meer controle over uw logische app en werkstromen. Standaard wordt verbinding 1 automatisch ingesteld voor het gebruik van de door het systeem toegewezen identiteit.

Als voor uw scenario een nauwkeurigere controle nodig is over het verifiëren van API-verbindingen, kunt u desgewenst de verificatie voor verbinding #1 wijzigen van de standaard door het systeem toegewezen identiteit in een door de gebruiker toegewezen identiteit die u aan uw logische app hebt toegevoegd. Deze verificatie is van toepassing op elke API-verbinding, zodat u door het systeem toegewezen en door de gebruiker toegewezen identiteiten kunt combineren tussen verschillende verbindingen met dezelfde doelresource.

In het connections.json-bestand van uw standaard logische app, waarin informatie over elke API-verbinding wordt opgeslagen, heeft elke verbindingsdefinitie twee authentication secties, bijvoorbeeld:

"keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity",
   },
   "connection": {
      "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  • De eerste authentication sectie wordt toegewezen aan verbinding 1.

    In deze sectie wordt de verificatie beschreven die wordt gebruikt voor de communicatie met het interne tokenarchief. In het verleden was deze sectie altijd ingesteld ManagedServiceIdentity op een app die in Azure wordt geïmplementeerd en geen configureerbare opties had.

  • De tweede authentication sectie wordt toegewezen aan verbinding 2.

    In deze sectie wordt beschreven welke verificatie wordt gebruikt voor de communicatie met de doelresource, afhankelijk van het verificatietype dat u voor die verbinding selecteert.

Waarom de verificatie voor het tokenarchief wijzigen?

In sommige scenario's wilt u mogelijk dezelfde API-verbinding delen en gebruiken voor meerdere logische app-resources, maar niet de door het systeem toegewezen identiteit voor elke logische app-resource toevoegen aan het toegangsbeleid van de doelresource.

In andere scenario's wilt u mogelijk niet dat de door het systeem toegewezen identiteit volledig is ingesteld voor uw logische app, zodat u de verificatie kunt wijzigen in een door de gebruiker toegewezen identiteit en de door het systeem toegewezen identiteit volledig kunt uitschakelen.

De verificatie voor het tokenarchief wijzigen

  1. Open uw resource voor de logische standaard-app in Azure Portal.

  2. Selecteer Verbinding maken ions in het resourcemenu onder Werkstromen.

  3. Selecteer JSON-weergave in het deelvenster Verbinding maken ions.

    Schermopname van de Azure-portal, de standaardresource van de logische app, Verbinding maken ions met de JSON-weergave geselecteerd.

  4. Zoek in de JSON-editor de managedApiConnections sectie, die de API-verbindingen bevat voor alle werkstromen in uw logische app-resource.

  5. Zoek de verbinding waaraan u een door de gebruiker toegewezen beheerde identiteit wilt toevoegen.

    Stel dat uw werkstroom een Azure Key Vault-verbinding heeft:

    "keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-region>/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity"
   },
   "connection": {
      "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/connections/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  6. Voer in de verbindingsdefinitie de volgende stappen uit:

    1. Zoek de eerste authentication sectie. Als er geen identity eigenschap in deze authentication sectie bestaat, gebruikt de logische app impliciet de door het systeem toegewezen identiteit.

    2. Voeg een identity eigenschap toe met behulp van het voorbeeld in deze stap.

    3. Stel de eigenschapswaarde in op de resource-id voor de door de gebruiker toegewezen identiteit.

    "keyvault": {
   "api": {
      "id": "/subscriptions/<Azure-subscription-ID>/providers/Microsoft.Web/locations/<Azure-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/<connector-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  7. Ga in Azure Portal naar de doelresource en geef toegang tot de door de gebruiker toegewezen beheerde identiteit op basis van de behoeften van de doelresource.

    Voeg bijvoorbeeld voor Azure Key Vault de identiteit toe aan het toegangsbeleid van de sleutelkluis. Wijs voor Azure Blob Storage de benodigde rol voor de identiteit toe aan het opslagaccount.

Beheerde identiteit uitschakelen

Als u de beheerde identiteit voor verificatie niet meer wilt gebruiken, verwijdert u eerst de toegang van de identiteit tot de doelresource. Schakel vervolgens in uw logische app-resource de door het systeem toegewezen identiteit uit of verwijder de door de gebruiker toegewezen identiteit.

Wanneer u de beheerde identiteit voor uw logische app-resource uitschakelt, verwijdert u de mogelijkheid voor die identiteit om toegang te vragen voor Azure-resources waar de identiteit toegang had.

Notitie

Als u de door het systeem toegewezen identiteit uitschakelt, werken alle verbindingen die worden gebruikt door werkstromen in de werkstroom van die logische app niet tijdens runtime, zelfs niet als u de identiteit onmiddellijk opnieuw inschakelt. Dit gedrag treedt op omdat het uitschakelen van de identiteit de object-id verwijdert. Telkens wanneer u de identiteit inschakelt, genereert Azure de identiteit met een andere en unieke object-id. U kunt dit probleem oplossen door de verbindingen opnieuw te maken, zodat deze de huidige object-id gebruiken voor de huidige door het systeem toegewezen identiteit.

Probeer te voorkomen dat de door het systeem toegewezen identiteit zoveel mogelijk wordt uitgeschakeld. Als u de toegang van de identiteit tot Azure-resources wilt verwijderen, verwijdert u de roltoewijzing van de identiteit uit de doelresource. Als u de resource van uw logische app verwijdert, verwijdert Azure automatisch de beheerde identiteit uit De Microsoft Entra-id.

De stappen in deze sectie hebben betrekking op het gebruik van de Azure-portal en azure Resource Manager-sjabloon (ARM-sjabloon). Raadpleeg de volgende documentatie voor Azure PowerShell, Azure CLI en Azure REST API:

Hulpprogramma Documentatie
Azure PowerShell 1. Roltoewijzing verwijderen.
2. Door de gebruiker toegewezen identiteit verwijderen.
Azure-CLI 1. Roltoewijzing verwijderen.
2. Door de gebruiker toegewezen identiteit verwijderen.
Azure REST API 1. Roltoewijzing verwijderen.
2. Door de gebruiker toegewezen identiteit verwijderen.

Zie Azure-roltoewijzingen verwijderen voor meer informatie.

Beheerde identiteit uitschakelen in Azure Portal

Als u de toegang voor de beheerde identiteit wilt verwijderen, verwijdert u de roltoewijzing van de identiteit uit de doelresource en schakelt u vervolgens de beheerde identiteit uit.

Roltoewijzing verwijderen

Met de volgende stappen verwijdert u de toegang tot de doelresource uit de beheerde identiteit:

  1. Ga in Azure Portal naar de Azure-doelresource waar u de toegang voor de beheerde identiteit wilt verwijderen.

  2. Selecteer toegangsbeheer (IAM) in het menu van de doelresource. Selecteer roltoewijzingen onder de werkbalk.

  3. Selecteer in de lijst met rollen de beheerde identiteiten die u wilt verwijderen. Selecteer Verwijderen op de werkbalk.

    Tip

    Als de optie Verwijderen is uitgeschakeld, hebt u waarschijnlijk geen machtigingen. Zie Beheer rolmachtigingen in Microsoft Entra ID voor meer informatie over de machtigingen waarmee u rollen voor resources kunt beheren.

Beheerde identiteit uitschakelen voor logische app-resource

  1. Open uw logische app-resource in Azure Portal.

  2. Selecteer Identiteit in het resourcemenu van de logische app onder Instellingen en volg vervolgens de stappen voor uw identiteit:

    • Selecteer Systeem toegewezen>bij>Opslaan. Wanneer u wordt gevraagd om te bevestigen, selecteert u Ja.

    • Selecteer Door de gebruiker toegewezen en de beheerde identiteit en selecteer vervolgens Verwijderen. Wanneer u wordt gevraagd om te bevestigen, selecteert u Ja.

Beheerde identiteit uitschakelen in een ARM-sjabloon

Als u de beheerde identiteit van de logische app hebt gemaakt met behulp van een ARM-sjabloon, stelt u de onderliggende eigenschap van type het identity object in op None.

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

Gerelateerde inhoud