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

In werkstromen van logische apps ondersteunen sommige triggers en acties het gebruik van een beheerde identiteit om de toegang tot resources te verifiëren die worden beveiligd door Azure Active Directory (Azure AD). Deze identiteit werd voorheen een Managed Service Identity (MSI) genoemd. Wanneer u uw logische app-resource inschakelt voor het gebruik van een beheerde identiteit voor verificatie, hoeft u geen referenties, geheimen of Azure AD tokens op te geven. Azure beheert deze identiteit en helpt verificatiegegevens veilig te houden, omdat u deze gevoelige informatie niet hoeft te beheren.

Azure Logic Apps ondersteunt de door het systeem toegewezen beheerde identiteit en de door de gebruiker toegewezen beheerde identiteit, maar de volgende verschillen bestaan tussen deze identiteitstypen:

  • Een resource voor logische apps 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 resources voor logische 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:

    Resourcetype logische app Omgeving Ondersteuning voor beheerde identiteiten
    Verbruik - Azure Logic Apps voor meerdere tenants

    - Integration Service Environment (ISE)

    - U kunt het door het systeem toegewezen identiteitstype of het door de gebruiker toegewezen identiteitstype inschakelen voor de resource van uw logische app.

    - Als deze optie is ingeschakeld met het door de gebruiker toegewezen identiteitstype, kan uw logische app-resource slechts één door de gebruiker toegewezen identiteit tegelijk hebben.

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

    Standard - Azure Logic Apps met één tenant

    - App Service Environment v3 (ASEv3)

    - Logic Apps met Azure Arc

    - U kunt zowel het door het systeem toegewezen identiteitstype inschakelen, dat standaard is ingeschakeld , als het door de gebruiker toegewezen identiteitstype tegelijk.

    - Uw resource voor logische apps kan tegelijkertijd meerdere door de gebruiker toegewezen identiteiten hebben.

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

Raadpleeg limieten voor beheerde identiteiten voor logische apps voor meer informatie over limieten voor beheerde identiteiten in Azure Logic Apps. Raadpleeg 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

Alleen specifieke ingebouwde en beheerde connectorbewerkingen die ondersteuning bieden voor Azure AD Open Authentication (Azure AD OAuth) kunnen een beheerde identiteit gebruiken voor verificatie. De volgende tabel bevat alleen een voorbeeldselectie. Raadpleeg verificatietypen voor triggers en acties die ondersteuning bieden voor verificatie en Azure-services die ondersteuning bieden voor Azure AD verificatie met beheerde identiteiten voor een volledige lijst.

De volgende tabel bevat de bewerkingen waarin u de door het systeem toegewezen beheerde identiteit of door de gebruiker toegewezen beheerde identiteit kunt gebruiken in het resourcetype logische app (verbruik ):

Het type bewerking Ondersteunde bewerkingen
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. Ze bieden echter geen ondersteuning voor de door de gebruiker toegewezen beheerde identiteit voor het verifiëren van dezelfde verbindingen.

Beheerde connector Eenmalige verificatie:
- Azure Automation
- Azure Event Grid
- Azure Key Vault
- Azure Resource Manager
- HTTP met Azure AD

Meervoudige verificatie:
- Azure Blob Storage
- Azure Event Hubs
- Azure Service Bus
- SQL Server

In dit artikel wordt beschreven hoe u de door het systeem toegewezen identiteit of door de gebruiker toegewezen identiteit inschakelt en instelt, op basis van of u het resourcetype logische app (verbruik) of logische app (standaard) gebruikt. In tegenstelling tot de door het systeem toegewezen identiteit, die u niet handmatig hoeft te maken , moet u de door de gebruiker toegewezen identiteit handmatig maken. Dit artikel bevat de stappen voor het maken van de door de gebruiker toegewezen identiteit met behulp 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 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, moet hetzelfde Azure-abonnement gebruiken.

  • Als u een beheerde identiteit toegang wilt geven tot een Azure-resource, moet u een rol toevoegen aan de doelresource voor die identiteit. Als u rollen wilt toevoegen, hebt u Azure AD beheerdersmachtigingen nodig waarmee rollen kunnen worden toegewezen aan identiteiten in de bijbehorende Azure AD tenant.

  • De Azure-doelresource waartoe u toegang wilt krijgen. In deze resource voegt u een rol toe voor de beheerde identiteit, waarmee de resource van de logische app of verbinding de toegang tot de doelresource kan worden geverifieerd.

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

Door het systeem toegewezen identiteit inschakelen in Azure Portal

  1. Open in de Azure Portal de resource van uw logische app.

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

  3. Selecteer inhet deelvenster Identiteit onder Door het systeem toegewezen de optie >Bij opslaan. Wanneer u wordt gevraagd om te bevestigen, selecteert u Ja.

    Screenshot showing Azure portal with Consumption logic app's

    Notitie

    Als u een foutmelding 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 Azure AD en wordt vertegenwoordigd door een object-id.

    Screenshot showing Consumption logic app's

    Eigenschap Waarde Beschrijving
    Object-id (principal) <id-resource-id> Een GUID (Globally Unique Identifier) die de door het systeem toegewezen identiteit voor uw logische app in een Azure AD-tenant vertegenwoordigt.
  4. Volg nu de stappen die deze identiteit toegang geven tot de resource verderop in dit onderwerp.

Door het systeem toegewezen identiteit inschakelen in een ARM-sjabloon

Als u het maken en implementeren van resources voor logische apps wilt automatiseren, kunt u een ARM-sjabloon gebruiken. Als u de door het systeem toegewezen beheerde identiteit voor uw logische app-resource in de sjabloon wilt inschakelen, voegt u het identity object en de type onderliggende eigenschap 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 identity object deze andere eigenschappen:

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

Door de gebruiker toegewezen identiteit maken in de Azure Portal

Voordat u de door de gebruiker toegewezen identiteit kunt inschakelen voor uw logische app -resource (verbruik) of logische app (standaard) moet u eerst die identiteit maken als een afzonderlijke Azure-resource.

  1. Typ in managed identitieshet zoekvak Azure Portal . Selecteer Beheerde identiteiten.

    Screenshot showing Azure portal with

  2. Selecteer Maken in het deelvenster Beheerde identiteiten.

    Screenshot showing

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

    Screenshot showing

    Eigenschap Vereist Waarde Beschrijving
    Abonnement Ja <Azure-subscription-name> De naam voor het te gebruiken Azure-abonnement
    Resourcegroep Ja <Naam-van-Azure-resourcegroep> De naam van de Azure-resourcegroep die u gaat gebruiken. 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 informatie over uw resource moet worden opgeslagen. 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 de resource van uw logische app.

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

  1. Open in de Azure Portal de resource van uw logische app.

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

  3. Selecteer in het deelvenster Identiteit de optie Door de gebruiker toegewezen>toevoegen.

    Screenshot showing Consumption logic app and

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

    1. Selecteer uw Azure-abonnement in de lijst Abonnement als dit nog niet is geselecteerd.

    2. Selecteer in de lijst met alle beheerde identiteiten in dat 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.

      Screenshot showing Consumption logic app and the user-assigned identity selected.

    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 beheerde identiteit.

    Screenshot showing Consumption logic app and association between user-assigned identity and logic app resource.

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

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 van resources uw sjabloon zijn deze items vereist voor de resourcedefinitie van uw logische app:

  • Een identity object waarop de type eigenschap is ingesteld op UserAssigned

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

In dit voorbeeld ziet u een resourcedefinitie voor een logische app voor verbruik voor een HTTP PUT-aanvraag en bevat een niet-geparameteriseerd identity object. Het antwoord op de PUT-aanvraag en de volgende GET-bewerking hebben ook dit identity object:

{
   "$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 identity object parameteriseren. In dit voorbeeld ziet u hoe het onderliggende userAssignedIdentities object verwijst naar een userAssignedIdentityName variabele die u in de sectie van variables uw sjabloon definieert. 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": {}
      }
  ]
}

Identiteit toegang geven 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-resource waarin u de identiteit wilt gebruiken. De manier waarop u toegang instelt, varieert op basis van de resource waartoe u toegang wilt krijgen tot de identiteit.

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.

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

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

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

Op rollen gebaseerde toegang op basis van beheerde identiteit toewijzen in de 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 de Azure Portal de resource waarin u de identiteit wilt gebruiken.

  2. Selecteer in het menu van de resource de optie Toegangsbeheer (IAM)>Roltoewijzing toevoegen>.

    Notitie

    Als de optie Roltoewijzing toevoegen is uitgeschakeld, hebt u geen machtigingen om rollen toe te wijzen. Raadpleeg Azure AD ingebouwde rollen voor meer informatie.

  3. Wijs nu 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 in dit voorbeeld de rol toe met de naam Storage Inzender voor blobgegevens, waaronder schrijftoegang voor blobs in een Azure Storage-container. Raadpleeg 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 aanbeheerde identiteit>Leden toevoegen.

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

    Type Azure-service-exemplaar Abonnement Lid
    Door het systeem toegewezen Logische app <Azure-subscription-name> <uw-logische app-naam>
    Door de gebruiker toegewezen Niet van toepassing <Azure-subscription-name> <uw-gebruiker-toegewezen-identity-name>

    Raadpleeg de documentatie, Rollen toewijzen met behulp van de Azure Portal voor meer informatie over het toewijzen van rollen.

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

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

Toegangsbeleid maken in de 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 de Azure Portal de doelresource waarin u de identiteit wilt gebruiken. In dit voorbeeld wordt een Azure-sleutelkluis gebruikt als doelresource.

  2. Selecteer in het menu van de resource Toegangsbeleid>maken, waarmee het deelvenster Toegangsbeleid maken wordt geopend.

    Notitie

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

    Screenshot showing the Azure portal and key vault example with

  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 beheerde Azure Key Vault-connector, heeft de identiteit lijstmachtigingen nodig. Selecteer in de kolom Machtigingen voor geheim de optie Lijst.

    Screenshot showing

  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 wordt beschreven hoe u een beheerde identiteit gebruikt om toegang te verifiëren voor een trigger of actie. 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 doelresource of entiteit, kunt u die identiteit gebruiken in triggers en acties die beheerde identiteiten ondersteunen.

Belangrijk

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

Deze stappen laten zien hoe u de beheerde identiteit gebruikt met een trigger of actie via de Azure Portal. Als u de beheerde identiteit wilt opgeven in de onderliggende JSON-definitie van een trigger of actie, controleert u verificatie van beheerde identiteiten.

  1. Open de resource van uw logische app in de Azure Portal.

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

    Notitie

    Niet alle triggers en acties ondersteunen het toevoegen van een verificatietype. Raadpleeg 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 bewerkingen die ondersteuning bieden voor verificatie van beheerde identiteiten

      1. Voeg in de lijst Nieuwe parameter toevoegen de eigenschap Verificatie toe als de eigenschap nog niet wordt weergegeven.

        Screenshot showing example built-in action with

      2. Selecteer beheerde identiteit in de lijst met verificatietypen.

        Screenshot showing example built-in action with

      Raadpleeg het 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 op de pagina tenantselectie Verbinding maken met beheerde identiteit, bijvoorbeeld:

        Screenshot showing Azure Resource Manager action and

      2. Geef op de volgende pagina voor verbindingsnaam een naam op die u voor de verbinding wilt gebruiken.

      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. Selecteer in de lijst met beheerde identiteiten de momenteel ingeschakelde beheerde identiteit, als deze nog niet is geselecteerd en selecteer vervolgens Maken, bijvoorbeeld:

          Screenshot showing the connection name page and single managed identity selected in Consumption.

        • Meervoudige verificatie: deze connectors bevatten meerdere verificatietypen, maar u kunt nog steeds slechts één type selecteren. Selecteer in de lijst Met verificatietypende optie Managed Identity>Create van Logic Apps, bijvoorbeeld:

          Screenshot showing the connection name page and

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

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 waartoe u toegang wilt krijgen:

Eigenschap Vereist Beschrijving
Methode Yes De HTTP-methode die wordt gebruikt door 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-resource of -service.
Kopteksten No Eventuele headerwaarden die u nodig hebt of die u wilt opnemen in de uitgaande aanvraag, zoals het inhoudstype
Query's No Queryparameters die u nodig hebt of die u wilt opnemen in de aanvraag. Queryparameters voor een specifieke bewerking of voor de API-versie van de bewerking die u wilt uitvoeren, bijvoorbeeld.
Verificatie Yes Het verificatietype dat moet worden gebruikt voor het verifiëren van de toegang tot de doelresource of entiteit

Stel dat u de momentopname-blobbewerking 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 HTTP-aanvragen en beheerde identiteiten, moet u ook uw opslagaccount instellen met de uitzondering die toegang toestaat door vertrouwde Microsoft-services.

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

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

x-ms-version = 2019-02-02

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

x-ms-versionDe x-ms-blob-typewaarden voor en x-ms-date headers zijn vereist voor Azure Storage bewerkingen.

Belangrijk: In 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. Dit x-ms-date 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.

Raadpleeg de volgende onderwerpen 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.

In het volgende voorbeeld ziet u een VOORBEELD van een HTTP-actie met alle eerder beschreven eigenschapswaarden die moeten worden gebruikt voor de bewerking Momentopname-blob:

Screenshot showing Azure portal with Consumption logic app workflow and HTTP action set up to access resource.

  1. Nadat u de HTTP-actie hebt toegevoegd, voegt u de eigenschap Verificatie toe aan de HTTP-actie. Selecteer Verificatie in de lijst Nieuwe parameter toevoegen.

    Screenshot showing Consumption workflow with HTTP action and

    Notitie

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

  2. Selecteer beheerde identiteit in de lijst met verificatietypen.

    Screenshot showing Consumption workflow with HTTP action and

  3. 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 als deze nog niet is geselecteerd.

      Screenshot showing Consumption workflow with HTTP action and

    • Als u een door de gebruiker toegewezen identiteit instelt, selecteert u die identiteit als deze nog niet is geselecteerd.

      Screenshot showing Consumption workflow with HTTP action and

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

  4. Bij sommige triggers en acties wordt de eigenschap Doelgroep ook weergegeven om de doelresource-id in te stellen. Stel de eigenschap Doelgroep in op de resource-id voor de doelresource of -service. Anders gebruikt de eigenschap Doelgroep standaard de https://management.azure.com/ resource-id. Dit is de resource-id voor Azure Resource Manager.

    Als u bijvoorbeeld toegang wilt verifiëren tot een Key Vault-resource in de globale Azure-cloud, moet u de eigenschap Doelgroep instellen op precies de volgende resource-id: https://vault.azure.net Deze specifieke resource-id heeft geen slashes. Het opnemen van een schuine slash kan zelfs een 400 Bad Request fout of een 401 Unauthorized fout opleveren.

    Belangrijk

    Zorg ervoor dat de doelresource-id exact overeenkomt met de waarde die Azure Active Directory (AD) verwacht, inclusief eventuele vereiste slashes. Voor de resource-id voor alle Azure Blob Storage-accounts is bijvoorbeeld een slash vereist. Voor de resource-id voor een specifiek opslagaccount is echter geen slash vereist. Controleer de resource-id's voor de Azure-services die ondersteuning bieden voor Azure AD.

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

    Screenshot showing Consumption workflow with HTTP action and

    Raadpleeg de volgende documentatie voor meer informatie over het autoriseren van toegang met Azure AD voor Azure Storage:

  5. Ga door met het bouwen van de werkstroom op de gewenste manier.

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.

  1. Nadat u de actie aan uw werkstroom hebt toegevoegd en uw Azure AD tenant hebt geselecteerd, selecteert u Verbinding maken met beheerde identiteit.

    Screenshot showing Azure Resource Manager action and

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

    De actie Azure Resource Manager is een actie met één verificatie. In het deelvenster Verbindingsgegevens wordt een lijst met beheerde identiteiten weergegeven waarmee automatisch de beheerde identiteit wordt geselecteerd die momenteel is ingeschakeld voor de resource van de logische app. Als u een door het systeem toegewezen beheerde identiteit hebt ingeschakeld, selecteert de lijst met beheerde identiteiten door het systeem toegewezen beheerde identiteit. Als u in plaats daarvan een door de gebruiker toegewezen beheerde identiteit hebt ingeschakeld, selecteert de lijst die identiteit.

    Als u een trigger of actie voor meerdere verificatie gebruikt, zoals Azure Blob Storage, wordt in het deelvenster Verbindingsinformatie een lijst met verificatietypen weergegeven met de optie Beheerde identiteit van Logic Apps onder andere verificatietypen.

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

    Screenshot showing Azure Resource Manager action with the connection name entered and

    Notitie

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

  3. Wanneer u klaar bent, selecteert u Maken.

  4. Nadat de ontwerper de verbinding heeft 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 de gewenste manier.

Resourcedefinitie 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. Tijdens runtime controleert de Azure Logic Apps-service of een beheerde connectortrigger en acties in de werkstroom van de logische app zijn ingesteld om de beheerde identiteit te gebruiken en of alle vereiste machtigingen zijn ingesteld om de beheerde identiteit te gebruiken voor toegang tot de doelbronnen die zijn opgegeven door de trigger en acties. Als dit lukt, haalt Azure Logic Apps het Azure AD token op dat is gekoppeld aan de beheerde identiteit en gebruikt deze identiteit om de toegang tot de doelresource te verifiëren en de geconfigureerde bewerking uit te voeren in trigger en acties.

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

In dit voorbeeld ziet u hoe de configuratie eruitziet wanneer de logische app de door het systeem toegewezen beheerde identiteit inschakelt:

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

In dit voorbeeld ziet u hoe de configuratie eruitziet wanneer de logische app een 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/{connection-name}",
            "connectionName": "{connection-name}",
            "connectionProperties": {
               "authentication": {
                  "type": "ManagedServiceIdentity",
                  "identity": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resourceGroupName}/providers/microsoft.managedidentity/userassignedidentities/{managed-identity-name}"
               }
            },
            "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region}/managedApis/{managed-connector-type}"
         }
      }
   }
}

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, zoals Office 365 Outlook, Azure Key Vault, enzovoort die gebruikmaakt van een beheerde identiteit, hebt u een extra stap die u moet uitvoeren.

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

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

Eenmalige verificatie

In dit voorbeeld ziet u de onderliggende verbindingsresourcedefinitie voor een actie Azure Automation in een logische app Verbruik die gebruikmaakt van een beheerde identiteit waarin de definitie de kenmerken bevat:

  • De eigenschap apiVersion is ingesteld op 2016-06-01.
  • De kind eigenschap is ingesteld op V1 voor een logische verbruiks-app.
  • De eigenschap parameterValueType is ingesteld op Alternative.
{
    "type": "Microsoft.Web/connections",
    "name": "[variables('connections_azureautomation_name')]",
    "apiVersion": "2016-06-01",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureautomation')]"
        },
        "customParameterValues": {},
        "displayName": "[variables('connections_azureautomation_name')]",
        "parameterValueType": "Alternative"
    }
},

Meervoudige verificatie

In dit voorbeeld ziet u de onderliggende verbindingsresourcedefinitie voor een actie Azure Blob Storage in een logische app Verbruik die gebruikmaakt van een beheerde identiteit waarin de definitie de volgende kenmerken bevat:

  • De eigenschap apiVersion is ingesteld op 2018-07-01-preview.
  • De kind eigenschap is ingesteld op V1 voor een logische verbruiks-app.
  • 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": "2018-07-01-preview",
    "name": "[variables('connections_azureblob_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues":{},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureblob')]"
        },
        "customParameterValues": {},
        "displayName": "[variables('connections_azureblob_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        }
    }
}

Geavanceerde controle over API-verbindingsverificatie instellen

Wanneer uw werkstroom gebruikmaakt van een API-verbinding, die wordt gemaakt door een beheerde connector, zoals Office 365 Outlook, Azure Key Vault, enzovoort, communiceert de Azure Logic Apps-service met de doelresource, zoals uw e-mailaccount, sleutelkluis, enzovoort, met behulp van twee verbindingen:

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

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

  • Verbinding 2 is ingesteld met verificatie voor de doelresource.

In een resource voor een logische app verbruik wordt de verbinding #1 zonder configuratieopties van u geabstraheerd. In het resourcetype Standaardlogica-app hebt u meer controle over uw logische app. Standaard wordt verbinding 1 automatisch ingesteld om de door het systeem toegewezen identiteit te gebruiken.

Als in uw scenario echter meer controle is vereist over het verifiëren van API-verbindingen, kunt u desgewenst de verificatie voor verbinding #1 wijzigen van de standaard door het systeem toegewezen identiteit aan een door de gebruiker toegewezen identiteit die u hebt toegevoegd aan uw logische app. 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 bestand Standard logic app connections.json , 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/{region}/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity",
   },
   "connection": {
      "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.net",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}
  • De eerste authentication sectie wordt toegewezen aan verbinding #1. In deze sectie wordt de verificatie beschreven die wordt gebruikt voor communicatie met het interne tokenarchief. In het verleden is deze sectie altijd ingesteld op ManagedServiceIdentity 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 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 apps, maar niet de door het systeem toegewezen identiteit voor elke logische app 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 in de Azure Portal de resource van de standaardlogica-app.

  2. Selecteer verbindingen in het resourcemenu onder Werkstromen.

  3. Selecteer JSON-weergave in het deelvenster Verbindingen.

    Screenshot showing the Azure portal, Standard logic app resource,

  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/{region}/managedApis/keyvault"
       },
       "authentication": {
          "type": "ManagedServiceIdentity"
       },
       "connection": {
          "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-name>"
       },
       "connectionProperties": {
          "authentication": {
             "audience": "https://vault.azure.net",
             "type": "ManagedServiceIdentity"
          }
       },
       "connectionRuntimeUrl": "<connection-runtime-URL>"
    }
    
  6. Voer in de verbindingsdefinitie de volgende stappen uit:

    1. Zoek de eerste authentication sectie. Als er al een 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/{region}/managedApis/keyvault"
       },
       "authentication": {
          "type": "ManagedServiceIdentity",
          // Add "identity" property here
          "identity": "/subscriptions/{Azure-subscription-ID}/resourcegroups/{resource-group-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{identity-resource-ID}" 
       },
       "connection": {
          "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-name>"
       },
       "connectionProperties": {
          "authentication": {
             "audience": "https://vault.azure.net",
             "type": "ManagedServiceIdentity"
          }
       },
       "connectionRuntimeUrl": "<connection-runtime-URL>"
    }
    
  7. Ga in de 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 uw logische app-resource verwijdert, verwijdert Azure automatisch de beheerde identiteit uit Azure AD.

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

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

Beheerde identiteit uitschakelen in de 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 de 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. Raadpleeg beheerdersrolmachtigingen in Azure Active Directory voor meer informatie over de machtigingen waarmee u rollen voor resources kunt beheren.

Beheerde identiteit uitschakelen in een logische app-resource

  1. Open de resource van uw logische app in de Azure Portal.

  2. Selecteer identiteit in het navigatiemenu van de logische app onder Instellingen en volg 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"
}

Volgende stappen