Delen via

Werkstroomverbindingen met beveiligde Azure-resources verifiëren met behulp van beheerde identiteiten in Azure Logic Apps

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

Stel een beheerde identiteit in wanneer u verbindingen van werkstromen van logische apps wilt verifiëren met met Microsoft Entra beveiligde Azure-resources. Deze identiteit opent beveiligde resources ten behoeve van uw logische app en elimineert de noodzaak om inloggegevens, geheimen of toegangstokens op te slaan en te beheren. Vanwege dit gedrag wordt een beheerde identiteit aanbevolen voor verificatie. Azure beheert deze identiteit om uw verificatiegegevens veilig te houden.

In Azure Logic Apps ondersteunen veel connectors beide typen beheerde identiteiten:

  • Door het systeem toegewezen identiteit
  • Door de gebruiker toegewezen identiteit

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

  • Stel de door het systeem toegewezen identiteit in voor uw logische app-resource.
  • Maak en stel een door de gebruiker toegewezen identiteit in uw logische app-resource in.

Deze handleiding bevat stappen voor de Azure-portal en azure Resource Manager-sjabloon (ARM-sjabloon). Zie voor Azure PowerShell, Azure CLI en Azure REST API:

Hulpmiddel Documentatie
Azure PowerShell - Door het systeem toegewezen
- Door de gebruiker toegewezen
Azure CLI - Door het systeem toegewezen
- Door de gebruiker toegewezen
Azure REST-API - Door het systeem toegewezen
- Door de gebruiker toegewezen

Voor meer informatie, zie:

Prerequisites

Overwegingen voor het gebruik van beheerde identiteiten

Bekijk de volgende overwegingen voordat u een beheerde identiteit met een logische app instelt en gebruikt:

  • Uw logische app-resource heeft slechts één unieke door het systeem toegewezen identiteit.

    Standaard schakelen standaard logische apps automatisch de door het systeem toegewezen identiteit in.

  • Uw logische app-resource kan de door het systeem toegewezen identiteit en een of meer door de gebruiker toegewezen identiteiten tegelijk hebben ingeschakeld.

    • Uw logische app kan de door het systeem toegewezen of een door de gebruiker toegewezen identiteit gebruiken, maar niet beide tegelijk.

    • Uw logische app kan slechts één door de gebruiker toegewezen identiteit tegelijk gebruiken.

  • Uw logische app-resource kan dezelfde door de gebruiker toegewezen identiteit delen in andere logische app-resources.

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

  • Voor standaard logische apps biedt de optie voor hybride implementatie geen ondersteuning voor verificatie van beheerde identiteiten. In plaats daarvan moet u een app-registratie maken en gebruiken.

Voor meer informatie, zie:

Connectors die beheerde identiteiten ondersteunen

Voor ingebouwde en beheerde connectorbewerkingen in Azure Logic Apps ter ondersteuning van verificatie van beheerde identiteiten moeten ze OAuth ondersteunen met Microsoft Entra.

In de volgende tabellen ziet u voorbeeldconnectors die ondersteuning bieden voor verificatie van beheerde identiteiten, op basis van het type logische app.

Verbindingslijntype 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 behulp van 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
- Microsoft Sentinel
- Azure Table Storage (opslagsysteem voor tabellen)
- Azure VM
- SQL Server

Zie voor een volledigere lijst:

Door het systeem toegewezen identiteit inschakelen (portal)

Volg de bijbehorende stappen voor Azure Portal op basis van uw type logische app:

Schakel handmatig de systeemaangewezen identiteit in van een Verbruik-logische app-resource.

  1. Open in de Azure portal uw resource voor de Consumption Logic App.

  2. Selecteer Identiteit in de zijbalk van de logische app onder Instellingen.

  3. Selecteer Op de pagina Identiteit , onder Systeem toegewezen, de optie Aan en selecteer Opslaan. Selecteer Ja om te bevestigen.

    Schermopname van de azure-portal, de pagina Verbruikslogica, de pagina Identiteit en het door het systeem toegewezen tabblad met geselecteerde opties, Aan en Opslaan.

    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 die de Identiteit-pagina van de Consumption logische app en de object-ID voor de door het systeem toegewezen identiteit toont.

    Eigenschap Waarde Beschrijving
    Object-ID (hoofd-id) < 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. Geef de identiteit toegang tot de beveiligde resource.

Door het systeem toegewezen identiteit (ARM-sjabloon) inschakelen

Als u het maken en implementeren van logische app-resources wilt automatiseren, gebruikt u een ARM-sjabloon.

In uw sjabloon, op hoofdniveau, is voor uw logische app-resourcedefinitie een identity object vereist dat de type eigenschap ingesteld heeft op SystemAssigned, bijvoorbeeld:

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

Wanneer Azure uw logische-app-resourcedefinitie maakt, krijgt het object identity de volgende eigenschappen: principalId en tenantId.

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

Een aan de gebruiker toegewezen identiteit maken (portal)

U moet de identiteit maken als een afzonderlijke Azure-resource voordat u de door de gebruiker toegewezen identiteit kunt inschakelen voor een logische app-resource van het type Verbruik of Standaard.

  1. Voer in het zoekvak van Azure Portal de tekst in managed identities. 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. Voer de gegevens van de beheerde identiteit in, bijvoorbeeld:

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

    Eigenschap Vereist Waarde Beschrijving
    Subscription Yes < Azure-abonnementnaam> De naam van het Azure-abonnement.
    Resourcegroep Yes < Azure-resourcegroep-naam> 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.
    Region Yes < Azure-regio> De Azure-regio waar u informatie over uw resource opslaat. In dit voorbeeld wordt West USgebruikt.
    Name Yes < door de gebruiker toegewezen identiteit-naam> De naam om uw door de gebruiker toegewezen identiteit te geven. In dit voorbeeld wordt Fabrikam-user-assigned-identitygebruikt.
    Isolatiebereik Nee - Geen (standaard)
    - Regio    		 Het effectieve bereik voor de beheerde identiteit.

  4. Wanneer u klaar bent, selecteert u Beoordelen en maken.

    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.

De door de gebruiker toegewezen identiteit toevoegen aan een Logic App (portal)

Nadat u de door de gebruiker toegewezen identiteit hebt gemaakt, voegt u de identiteit toe aan uw Verbruik- of Standard-logische-appresource.

  1. Open in de Azure-portal uw Verbruik-logica-app-resource.

  2. Selecteer Identiteit in de zijbalk van de logische app onder Instellingen.

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

    Schermopname van een logische app voor verbruik 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 beheerde identiteiten 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, bijvoorbeeld:

      Schermopname van een Consumptie-logische app en de door de gebruiker toegewezen identiteit.

    3. Wanneer u klaar bent, selecteert u Toevoegen.

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

    Schermopname toont een Verbruikslogica-app met gekoppelde gebruiker-toegewezen identiteit.

  5. Geef de identiteit toegang tot de beveiligde resource.

Door de gebruiker toegewezen identiteit (ARM-sjabloon) maken

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

In de sectie van uw sjabloon resources zijn voor de resourcedefinitie van uw logic app de volgende items vereist.

  • Een identity object waarop de type eigenschap is ingesteld op UserAssigned.
  • Een kindobject userAssignedIdentities dat de door de gebruiker toegewezen bron en naam aangeeft.

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

Een logische consumptie-app-voorziening kan zodanig worden ingeschakeld dat zowel de door het systeem toegewezen identiteit als meerdere door de gebruiker toegewezen identiteiten worden gedefinieerd.

{
   "$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 de resourcedefinitie van de beheerde identiteit bevat, kunt u het identity object parameteriseren. In het volgende voorbeeld wordt getoond hoe het userAssignedIdentities-kindobject verwijst naar een userAssignedIdentityName-variabele die u definieert in de variables-sectie 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": {}
      }
  ]
}

Wanneer de sjabloon de resourcedefinitie van uw logische app maakt, bevat het identity object de volgende principalId en clientId eigenschappen:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<resource-ID>": {
            "principalId": "<principal-ID>",
            "clientId": "<client-ID>"
        }
    }
}
Eigenschap (JSON) Waarde Beschrijving
principalId < principal-id> De GUID (Globally Unique Identifier) die Microsoft Entra gebruikt om het service-principal-object voor uw beheerde identiteit in de Microsoft Entra-tenant te beheren. Deze GUID wordt soms weergegeven als een object-id of objectID. In de Microsoft Entra-tenant heeft de service-principal dezelfde naam als het exemplaar van de Logic-app.
clientId < client-id> De GUID (Globally Unique Identifier) die de identiteit van de logische app vertegenwoordigt en geeft de identiteit op die moet worden gebruikt tijdens runtime-aanroepen.

Zie ARM-sjabloon - Azure Functions voor meer informatie over Azure Resource Manager-sjablonen en beheerde identiteiten voor Azure Functions.

Resourcetoegang verlenen tot een identiteit

Voordat u de beheerde identiteit voor verificatie kunt gebruiken, moet u de identiteit toegang verlenen tot de met het doel beveiligde Azure-resource. De manier waarop u toegang instelt, kan verschillen op basis van de doelresource, bijvoorbeeld:

  • Toegangsbeheer op basis van rollen in Azure (RBAC)

    Voor sommige Azure-resources, zoals opslagaccounts, moet u RBAC gebruiken om een rol toe te wijzen aan de doelresource met de benodigde machtigingen voor uw identiteit.

    Als u bijvoorbeeld een beheerde identiteit toegang wilt geven tot een Blob Storage-account in Azure, moet u de benodigde Azure-rol in de opslagaccountresource toewijzen aan uw identiteit.

    In deze sectie wordt beschreven hoe u een rol toewijst met behulp van de Azure-portal en de Azure Resource Manager-sjabloon (ARM-sjabloon).

    Zie voor Azure PowerShell, Azure CLI en Azure REST API:

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

  • Toegangsbeleid

    Met andere Azure-resources, zoals sleutelkluizen, kunt u ook een toegangsbeleid voor de doelresource maken met de benodigde machtigingen voor uw identiteit.

    U kunt bijvoorbeeld een toegangsbeleid maken voor de sleutelkluisresource om de benodigde machtigingen voor uw beheerde identiteit toe te wijzen.

    In deze sectie ziet u hoe u een toegangsbeleid maakt met behulp van Azure Portal.

    Zie voor Resource Manager-sjablonen, Azure PowerShell en Azure CLI:

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

Beheerde identiteitstoegang tot middelen op een hoger niveau

Als een beheerde identiteit toegang heeft tot een resource in hetzelfde abonnement, heeft de identiteit alleen toegang tot die resource, niet tot andere resources in de bovenliggende hiërarchie van die resource. Voor sommige triggers en acties in de werkstroomontwerper moet u eerst een abonnement of resourcegroep selecteren voordat u de doelresource kunt selecteren. Als de identiteit geen toegang heeft tot deze resources op een hoger niveau, laat de ontwerper de doelbron niet zien.

U kunt dit probleem oplossen door de identiteit toegang te geven tot elke resource op een hoger niveau die u eerst moet selecteren.

In andere gevallen heeft de identiteit ook toegang nodig tot de resource waarin u de identiteit hebt ingeschakeld. Stel dat u een werkstroomactie hebt waarmee de toepassingsinstellingen in de bovenliggende logische app van de werkstroom worden bijgewerkt. Indien de actie een beheerde identiteit gebruikt om toegang te krijgen tot deze instellingen, verleent u die identiteit toegang tot de bovenliggende logic app.

Op rollen gebaseerde toegang toewijzen aan een beheerde identiteit (portal)

Voer de volgende stappen uit voor Azure-resources waarvoor u een rol voor uw beheerde identiteit moet toewijzen:

  1. Open in Azure Portal de resource waar de identiteit toegang nodig heeft.

    In dit voorbeeld wordt een opslagaccount gebruikt als doelresource van Azure.

  2. Selecteer toegangsbeheer (IAM) op de zijbalk van de resource.

  3. Selecteer op de paginawerkbalk toegangsbeheer (IAM) de optie Toevoegen>Roltoewijzing toevoegen.

    Opmerking

    Als u roltoewijzing toevoegen niet kunt selecteren, hebt u niet de machtigingen om rollen toe te wijzen. U hebt microsoft Entra-beheerdersmachtigingen nodig, zodat u rollen kunt toewijzen aan beheerde identiteiten.

  4. Voer de volgende stappen uit om de vereiste rol toe te wijzen aan uw beheerde identiteit:

    1. Zoek en selecteer op het tabblad Rol de ingebouwde Microsoft Entra-rol die uw identiteit de vereiste toegang geeft tot de huidige resource en selecteer vervolgens Volgende.

      In dit voorbeeld wordt de rol Storage Blob Data Contributor geselecteerd. Deze rol geeft schrijftoegang tot blob-inhoud in een Azure-opslagcontainer.

      Zie Rollen voor toegang tot blob-inhoud in een Azure-opslagcontainer voor meer informatie.

    2. Voer op het tabblad Leden de volgende stappen uit om de beheerde identiteit te selecteren:

      1. Voor Toegang toewijzen aan, selecteer Beheerde identiteit.

      2. Voor Leden toevoegen selecteert u + Leden selecteren.

      3. Selecteer op het deelvenster Beheerde identiteiten uw Azure-abonnement.

      4. Selecteer op basis van uw beheerde identiteit het type beheerde identiteit en selecteer vervolgens uw beheerde identiteit.

        Type beheerde identiteit Beschrijving
        Door de gebruiker toegewezen beheerde identiteit Bekijk en selecteer een door de gebruiker toegewezen beheerde identiteit in een Azure-resource.
        Alle door het systeem toegewezen beheerde identiteiten Bekijk en selecteer een door het systeem toegewezen beheerde identiteit in een Azure-resource.
        Logische app Alleen een ingeschakelde beheerde identiteit voor logische app-resources weergeven en selecteren.

      5. Wanneer u klaar bent, selecteert u Selecteren.

    Voor meer informatie, zie:

  5. Verifieer uw trigger of actie met behulp van de beheerde identiteit.

Een toegangsbeleid maken in Azure Portal

Voer de volgende stappen uit voor Azure-resources waar u een toegangsbeleid voor uw beheerde identiteit wilt maken:

  1. Open in Azure Portal de resource waar de identiteit toegang nodig heeft.

    In dit voorbeeld wordt een sleutelkluis gebruikt als Azure-doelresource.

  2. Selecteer toegangsbeleid op de zijbalk van de resource.

    Opmerking

    Als de resource niet beschikt over de optie Toegangsbeleid , wijst u in plaats daarvan een rol toe.

  3. Selecteer Maken op de paginawerkbalk om het deelvenster Een toegangsbeleid maken te openen.

    Schermopname toont de Azure portal en een voorbeeld van een sleutelkluis met het deelvenster genaamd 'Een toegangsbeleid maken' dat geopend is.

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

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

    Schermopname van het tabblad Machtigingen met geselecteerde lijstmachtigingen.

  5. Wanneer u klaar bent, selecteert u Volgende.

  6. Selecteer op het tabblad Principal de beheerde identiteit.

    In dit voorbeeld wordt een door de gebruiker toegewezen identiteit geselecteerd.

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

  8. Verifieer uw trigger of actie met behulp van de beheerde identiteit.

Toegang verifiëren met behulp van de beheerde identiteit

In deze sectie wordt beschreven hoe u een beheerde identiteit gebruikt om toegang te verifiëren voor een werkstroomtrigger of -actie die ondersteuning biedt voor verificatie van beheerde identiteiten. Het voorbeeld gaat verder vanaf de locatie waar u toegang instelt voor een beheerde identiteit met behulp van RBAC en een Azure-opslagaccount. Hoewel uw Azure-doelresource kan verschillen, zijn de algemene stappen meestal vergelijkbaar.

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.

In de volgende stappen ziet u hoe u de beheerde identiteit gebruikt met behulp van Azure Portal. Zie Verificatie van beheerde identiteiten als u de beheerde identiteit in de onderliggende JSON-definitie wilt gebruiken met behulp van de code-editor.

  1. Open in de Azure portal uw resource voor de Consumption Logic App.

  2. Voeg de trigger of actie toe die beheerde identiteiten ondersteunt, als u dat nog niet hebt gedaan.

  3. Voer bij de trigger of actie de volgende stappen uit:

    • Ingebouwde bewerkingen

      In deze stappen wordt de HTTP-actie als voorbeeld gebruikt.

      1. Selecteer de verificatieparameter in de lijst Geavanceerde parameters.

        Schermopname van een verbruikswerkstroom met ingebouwde HTTP-actie en geopende lijst met de naam Geavanceerde parameters, met de geselecteerde optie voor verificatie.

        Zowel de verificatieparameter als de lijst met verificatietypen worden weergegeven, bijvoorbeeld:

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

      2. Selecteer Beheerde identiteit in de lijst Verificatietype.

        Schermopname van een werkstroom met een ingebouwde actie, lijst met geopende verificatietypen en geselecteerde optie voor beheerde identiteit.

        In de sectie Verificatie ziet u nu de volgende opties:

        Parameter Beschrijving
        beheerde identiteit De beheerde identiteit die moet worden gebruikt.
        Audiëntie Wordt weergegeven op specifieke triggers en acties, zodat u de resource-id voor de Azure-doelresource of -service kunt instellen.

        De parameter Doelgroep gebruikt standaard de https://management.azure.com/ resource-id. Dit is de resource-id voor Azure Resource Manager.

      3. Selecteer in de lijst met beheerde identiteiten de gewenste identiteit, bijvoorbeeld:

        Schermopname van de sectie Authenticatie met de lijst Authenticatietype en de eigenschap Doelgroep.

        Opmerking

        Standaard is door het systeem toegewezen beheerde identiteit de geselecteerde optie, zelfs wanneer u geen beheerde identiteiten inschakelt. Als u de beheerde identiteit echter wilt gebruiken, moet u die identiteit eerst inschakelen in uw logische app. Bij consumptie-logische apps wordt de systeemidentiteit niet automatisch ingeschakeld, in tegenstelling tot standaard-logische apps.

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

    • Beheerde connectorbewerkingen

      1. Selecteer in het deelvenster Verbinding maken in de lijst Verificatie beheerde identiteit, bijvoorbeeld:

        De schermafbeelding toont de verbruikswerkstroom met de Azure Resource Manager-actie en de geselecteerde optie voor beheerde identiteit.

      2. Voer in het volgende deelvenster voor Verbindingsnaam een naam in die u voor de verbinding wilt gebruiken.

      3. Kies op basis van uw connector een van de volgende opties:

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

          In de volgende stappen wordt een Azure-resourceactie gebruikt als voorbeeld:

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

          2. Selecteer Nieuw maken.

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

          In de volgende stappen wordt een Azure Blob Storage-actie gebruikt als voorbeeld:

          1. Selecteer in de lijst Verificatietypede 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. Selecteer Nieuw 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:

Eigenschap Vereist Beschrijving
Method Yes De HTTP-methode voor de bewerking die u wilt uitvoeren
URI Yes 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.
Headers Nee Koptekstwaarden die u nodig hebt of die u wilt opnemen in de uitgaande aanvraag, zoals het inhoudstype
Queries 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.
Authentication Yes 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:

Eigenschap Vereist Voorbeeldwaarde Beschrijving
URI Yes 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.
Method Yes PUT De HTTP-methode die wordt gebruikt door de snapshot-blobbewerking.
Headers 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 waarde moet de huidige datum zijn. Anders mislukt uw werkstroom met een 403 FORBIDDEN foutmelding. Als u de huidige datum in de vereiste notatie wilt ophalen, kunt u de expressie in de voorbeeldwaarde gebruiken.

Zie voor meer informatie:

- Aanvraagheaders - Momentopname-blob
- Versiebeheer voor Azure Storage-services
Queries 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. Selecteer Verificatie in de HTTP-actie in de lijst geavanceerde parameters.

    Schermopname toont de Verbruikswerkstroom met de HTTP-actie, en de lijst met geavanceerde parameters is geopend met de geselecteerde eigenschap genaamd Authenticatie.

    De sectie Verificatie wordt weergegeven in uw HTTP-actie .

  3. Selecteer Beheerde identiteit uit de Verificatietype-lijst.

    Schermopname toont de Consumptiewerkstroom, de HTTP-actie en de eigenschap Verificatietype met de geselecteerde optie voor Beheerde Identiteit.

  4. Selecteer in de lijst met beheerde identiteiten 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 Verbruikswerkstroom, HTTP-actie en Beheerde identiteit 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 toont Verbruikswerkstroom, HTTP-actie en Beheerde identiteit met een 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 doelgroepparameter weergegeven, zodat u de resource-id voor de Azure-doelresource of -service kunt invoeren.

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

    Anders gebruikt de doelgroepparameter standaard de https://management.azure.com/ resource-id. Dit is de resource-id voor Azure Resource Manager.

    Belangrijk

    De doelresource-ID moet exact overeenkomen met de waarde die Microsoft Entra ID verwacht. Anders krijgt u mogelijk de fout 400 Ongeldige aanvraag of een fout 401 Niet-geautoriseerd . Als de resource-id afsluitende slashes bevat, neem deze dan op. Zo niet, neem ze dan 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 het volgende voorbeeld wordt de doelgroepparameter ingesteld op https://storage.azure.com/. Deze waarde betekent dat de toegangstokens voor verificatie geldig zijn voor alle opslagaccounts. Geef voor een specifiek opslagaccount de URL van de hoofdservice op. https://<your-storage-account>.blob.core.windows.net

    Schermopname toont de consumptiewerkstroom en de HTTP-actie, waarbij de eigenschap publiek is ingesteld op de doelresource-id.

    Voor meer informatie, zie:

  6. Ga door met het bouwen van de werkstroom op basis van uw scenario.

Voorbeeld: Acties of triggers van beheerde connectoren authentiseren met behulp van een beheerde identiteit

De beheerde Azure Resource Manager-connector heeft een actie genaamd Een resource lezen die de beheerde identiteit kan gebruiken die u inschakelt voor uw logica-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 in de lijst Verificatie de optie Beheerde identiteit en selecteer Vervolgens Aanmelden.

    Opmerking

    In sommige connectors wordt in de lijst Verificatietype de beheerde identiteit van Logic Apps weergegeven. Als in uw scenario deze optie wordt weergegeven, selecteert u deze optie.

    Schermopname toont de werkstroom voor Verbruik, de Azure Resource Manager-actie, de geopende lijst met verificaties, en de geselecteerde optie voor beheerde identiteit.

  3. Voer een naam in voor de verbinding en selecteer de gewenste beheerde identiteit.

    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.

    Opmerking

    Als u de beheerde identiteit niet inschakelt wanneer u de verbinding probeert te maken of wijzigen, of als u de beheerde identiteit verwijdert 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.

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

  5. Ga door met het bouwen van de werkstroom op basis van uw scenario.

Verbindingen met beheerde identiteiten in resourcedefinities van logische apps

Een geverifieerd verbindingstype voor een beheerde identiteit is een speciaal verbindingstype dat alleen werkt met een beheerde identiteit. Tijdens de werkstroom-runtime gebruikt de verbinding de beheerde identiteit die is ingeschakeld voor de resource van de Logic App. Azure Logic Apps controleert of bewerkingen van een beheerde connector in de werkstroom de beheerde identiteit gebruiken en of alle vereiste machtigingen bestaan om de beheerde identiteit te gebruiken voor toegang tot de bijbehorende doelresources. 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 toegang tot de Azure-doelresources te verifiëren en voert u de bijbehorende bewerkingen uit in de werkstroom.

In een Consumption-logische app-resource slaat u de verbindingsconfiguratie op in het parameters-object van de resourcedefinitie. Dit object bevat het $connections object met aanwijzers naar de resource-id van de verbinding, samen met de resource-id van de beheerde identiteit wanneer u de door de gebruiker toegewezen identiteit inschakelt.

In het volgende voorbeeld ziet u het object wanneer de door het parameterssysteem toegewezen identiteit is ingeschakeld voor een logische app:

"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 het volgende voorbeeld ziet u het parameters object wanneer de door de gebruiker toegewezen beheerde identiteit is ingeschakeld voor een logische app:

"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 is gemaakt door een beheerde connector en een beheerde identiteit gebruikt, moet u een extra stap uitvoeren.

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

De volgende voorbeelden zijn van toepassing op Consumptielogische app-resources. Ze laten zien hoe de onderliggende connectorresourcedefinitie verschilt tussen een connector met één verificatie en een connector voor meervoudige verificatie.

Eénvoudige authenticatie

In dit voorbeeld ziet u de onderliggende definitie van de verbindingsresource voor een connectoractie die slechts één verificatietype ondersteunt en gebruikmaakt van een beheerde identiteit in een consumptie-logica-app workflow. De definitie bevat de volgende kenmerken:

  • De kind eigenschap is ingesteld op V1 voor een verbruikswerkstroom.

  • 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'), '<connector-name>')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_<connector-name>_name')]",
        "parameterValueSet": {},
        "parameterValueType": "Alternative"
    }
},

Meerdere verificatiemethoden

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. De definitie bevat de volgende kenmerken:

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

  • 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'), '<connector-name>')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_<connector-name>_name')]",
        "parameterValueSet": {
            "name": "managedIdentityAuth",
            "values": {}
        }
    }
}

Geavanceerd beheer instellen voor API-verbindingsverificatie

Wanneer uw standaardwerkstroom voor logische apps een API-verbinding gebruikt die door een beheerde connector wordt gemaakt, gebruikt Azure Logic Apps twee verbindingen om te communiceren met de doelresource, zoals uw e-mailaccount of sleutelkluis:

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

  • Verbinding #1 is ingesteld met authenticatie voor de interne tokenopslag.

  • Verbinding 2 is ingesteld met verificatie voor de doelresource.

Wanneer een werkstroom van een verbruikslogica-app gebruikmaakt van een API-verbinding, kunt u verbinding #1 niet weergeven of instellen. Als u een resource voor een standaard logische app gebruikt, krijgt u meer controle over uw logische app en werkstromen. Standaard maakt verbinding #1 gebruik van de door het systeem toegewezen identiteit.

Als uw scenario nauwkeurige controle vereist over het verifiëren van API-verbindingen, wijzigt u de verificatie voor verbinding #1 van de standaard door het systeem toegewezen identiteit in een door de gebruiker toegewezen identiteit die u aan uw logische app toevoegt. 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 objecten, 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>"
}

  • Het eerste authentication object wordt toegewezen aan verbinding 1.

    Dit object beschrijft de verificatie die wordt gebruikt voor de communicatie met het interne tokenarchief. In het verleden was de type eigenschap altijd ingesteld ManagedServiceIdentity op een app die in Azure wordt geïmplementeerd en geen configureerbare opties had.

  • Het tweede authentication object wordt toegewezen aan verbinding 2.

    Dit object beschrijft de verificatie die wordt gebruikt voor de communicatie met de doelresource en kan variëren, afhankelijk van het verificatietype dat u voor die verbinding selecteert.

Waarom de verificatie voor de tokenopslag wijzigen?

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

In andere scenario's wilt u mogelijk niet de door het systeem toegewezen identiteit instellen voor uw logische app. Als u in plaats daarvan een door de gebruiker toegewezen identiteit wilt gebruiken, kunt u de verificatie wijzigen in een door de gebruiker toegewezen identiteit en de door het systeem toegewezen identiteit volledig uitschakelen.

De verificatie voor de tokenopslag wijzigen

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

  2. Selecteer Verbindingen in de zijbalk van de resource onder Werkstromen.

  3. Selecteer JSON-weergave in het deelvenster Verbindingen.

    Schermopname van de Azure-portal, resource van een standaard logische app, deelvenster Verbindingen met de JSON-weergave geselecteerd.

  4. Zoek het managedApiConnections object in de JSON-editor. Dit object bevat de API-verbindingen 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 het eerste authentication object. Als er geen identity eigenschap in dit authentication object 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, voert u de volgende stappen uit:

  1. Verwijder de toegang van de identiteit tot de doelresource.

  2. Schakel 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 tot Azure-resources waar de identiteit toegang had.

Opmerking

Als u de door het systeem toegewezen identiteit uitschakelt, werken alle verbindingen die gebruikmaken van de identiteit in de werkstromen van de logische app niet meer tijdens runtime, zelfs 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 ze de huidige object-id gebruiken voor de huidige door het systeem toegewezen identiteit.

Vermijd het uitschakelen van de door het systeem toegewezen identiteit zoveel mogelijk. 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 logica-app verwijdert, verwijdert Azure automatisch de beheerde identiteit uit Microsoft Entra-ID.

In de volgende secties ziet u hoe u de beheerde identiteit kunt uitschakelen met behulp van de Azure-portal en de Azure Resource Manager-sjabloon (ARM-sjabloon). Zie voor Azure PowerShell, Azure CLI en Azure REST API:

Hulpmiddel 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 de zijbalk 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.

    Opmerking

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

Beheerde identiteit uitschakelen voor Logic App-resource

  1. Open in de Azure-portal uw Logic-app-resource.

  2. Selecteer Identiteit in de zijbalk van de logische app-resource onder Instellingen en volg de stappen voor uw identiteit:

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

    • Selecteer Door de gebruiker toegewezen en de beheerde identiteit, en selecteer vervolgens op 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 identity onderliggende eigenschap van het type object in op None.

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

Verwante inhoud

  • Last updated on