Freigeben über

Authentifizieren von Workflowverbindungen mit geschützten Azure-Ressourcen mithilfe von verwalteten Identitäten in Azure Logic Apps

Gilt für: Azure Logic Apps (Verbrauch + Standard)

Richten Sie eine verwaltete Identität ein, wenn Sie Verbindungen von Logik-App-Workflows zu microsoft entra-geschützten Azure-Ressourcen authentifizieren möchten. Diese Identität greift im Auftrag Ihrer Logik-App auf geschützte Ressourcen zu und entfernt die Notwendigkeit zum Speichern und Verwalten von Anmeldeinformationen, geheimen Schlüsseln oder Zugriffstoken. Aufgrund dieses Verhaltens wird eine verwaltete Identität für die Authentifizierung empfohlen. Azure verwaltet diese Identität, um Ihre Authentifizierungsdetails sicher zu halten.

In Azure Logic Apps unterstützen viele Connectors beide verwalteten Identitätstypen:

  • Vom System zugewiesene Identität
  • Vom Benutzer zugewiesene Identität

In diesem Leitfaden wird gezeigt, wie Sie die folgenden Aufgaben ausführen:

  • Richten Sie die vom System zugewiesene Identität für Ihre Logik-App-Ressource ein.
  • Erstellen und Einrichten einer vom Benutzer zugewiesenen Identität für Ihre Logik-App-Ressource.

Dieses Handbuch enthält Schritte für das Azure-Portal und die Azure Resource Manager-Vorlage (ARM-Vorlage). Informationen zu Azure PowerShell, Azure CLI und Azure REST-API finden Sie unter:

Tool Dokumentation
Azure PowerShell - Vom System zugewiesen
- Benutzer zugewiesen
Azure CLI - Vom System zugewiesen
- Benutzer-zugewiesen
Azure-REST-API - Vom System zugewiesen
- Benutzer-zugewiesen

Weitere Informationen findest du unter:

Voraussetzungen

  • Ein Azure-Konto und ein Azure-Abonnement. Erhalten Sie ein kostenloses Azure-Konto.

    Sie müssen dasselbe Azure-Abonnement für Ihre Logik-App-Ressource, verwaltete Identität und Azure-Zielressource verwenden, auf die Sie zugreifen möchten.

  • Die Logik-App-Ressource und der Workflow, in dem Sie die verwaltete Identität verwenden möchten.

    Weitere Informationen findest du unter:

  • Die Azure-Zielressource, auf die Sie zugreifen möchten.

  • Microsoft Entra-Administratorberechtigungen.

    Später in diesem Leitfaden müssen Sie der verwalteten Identität eine Azure-Rolle mit dem erforderlichen Zugriff auf die Zielressource zuweisen. Für diese Aufgabe benötigen Sie Berechtigungen, mit denen Sie Azure-Rollen Identitäten in einem Microsoft Entra-Mandanten zuweisen können.

Überlegungen zur Verwendung von verwalteten Identitäten

Bevor Sie eine verwaltete Identität mit einer Logik-App einrichten und verwenden, lesen Sie die folgenden Überlegungen:

  • Ihre Logik-App-Ressource verfügt nur über eine eindeutige systembasierte Identität.

    Standardmäßig aktivieren Standardlogik-Apps automatisch die vom System zugewiesene Identität.

  • Ihre Logik-App-Ressource kann die vom System zugewiesene Identität und eine oder mehrere vom Benutzer zugewiesene Identitäten gleichzeitig aktiviert haben.

    • Ihre Logik-App kann entweder die vom System zugewiesene oder eine vom Benutzer zugewiesene Identität verwenden, aber nicht beide gleichzeitig.

    • Ihre Logik-App kann jeweils nur eine vom Benutzer zugewiesene Identität verwenden.

  • Ihre Logik-App-Ressource kann dieselbe vom Benutzer zugewiesene Identität für andere Logik-App-Ressourcen gemeinsam nutzen.

  • Sie können eine verwaltete Identität auf Ressourcenebene der Logik-App und auf Verbindungsebene verwenden.

  • Bei Standardlogik-Apps unterstützt die Hybridbereitstellungsoption keine verwaltete Identitätsauthentifizierung. Stattdessen müssen Sie stattdessen eine App-Registrierung erstellen und verwenden.

Weitere Informationen findest du unter:

Konnektoren, die verwaltete Identitäten unterstützen

Für integrierte und verwaltete Connectorvorgänge in Azure Logic Apps zur Unterstützung der verwalteten Identitätsauthentifizierung müssen sie OAuth mit Microsoft Entra unterstützen.

Die folgenden Tabellen zeigen Beispiel-Connectors, die die Authentifizierung mit verwalteter Identität je nach Typ der Logik-App unterstützen.

Connectortyp Unterstützte Connectors
Integriert – Azure API Management
– Azure App Services
– Azure Functions
– HTTP
– HTTP + Webhook

Hinweis: HTTP-Vorgänge können Verbindungen mit Azure Storage-Konten hinter Azure-Firewalls authentifizieren, indem die vom System zugewiesene Identität verwendet wird. HTTP-Vorgänge unterstützen jedoch nicht die benutzerseitig zugewiesene verwaltete Identität für die Authentifizierung derselben Verbindungen.
Verwaltet – Azure App Service
– Azure Automation
– Azure Blob Storage
- Azure-Containerinstanz
– 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-Protokolle
- Azure-Warteschlangen
– Azure Resource Manager
– Azure Service Bus
– Microsoft Sentinel
– Azure Table Storage
- virtueller Azure-Computer
- SQL Server

Eine vollständigere Liste finden Sie unter:

Aktivieren der vom System zugewiesenen Identität (Portal)

Führen Sie basierend auf Ihrem Logik-App-Typ die entsprechenden Schritte für das Azure-Portal aus:

Aktivieren Sie bei einer Ressource der Verbrauchslogik-App die vom System zugewiesene Identität manuell.

  1. Öffnen Sie im Azure-Portal Ihre Logik-App-Ressource (Verbrauch).

  2. Wählen Sie auf der Randleiste der Logik-App unter "Einstellungen" die Option "Identität" aus.

  3. Wählen Sie auf der Seite „Identität“ unter „System zugewiesen“ die Option „Ein“ und dann „Speichern“ aus. Klicken Sie zum Bestätigen auf Ja.

    Ein Screenshot zeigt das Azure-Portal, die Consumption Logic Apps, die Seite „Identität“ und die Registerkarte „System zugewiesen“ mit den ausgewählten Optionen Ein und Speichern.

    Ihre Logik-App-Ressource kann jetzt die vom System zugewiesene Identität verwenden. Diese Identität wird bei Microsoft Entra ID registriert und durch eine Objekt-ID dargestellt.

    Ein Screenshot zeigt die Seite Identität der Consumption Logic App und die Objekt-ID für die vom System zugewiesene Identität.

    Eigenschaft Wert BESCHREIBUNG
    Objekt-ID (Prinzipal) < ID_der_Identitätsressource> Eine GUID (Globally Unique Identifier), die die systemseitig zugewiesene Identität für Ihre Logik-App in einem Microsoft Entra-Mandanten angibt

  4. Gewähren Sie der Identität Zugriff auf die geschützte Ressource.

Aktivieren der vom System zugewiesenen Identität (ARM-Vorlage)

Verwenden Sie eine ARM-Vorlage, um das Erstellen und Bereitstellen von Logik-App-Ressourcen zu automatisieren.

In Ihrer Vorlage benötigt die Logik-App-Ressourcendefinition auf der Stammebene ein identity-Objekt, bei dem die type-Eigenschaft auf SystemAssigned festgelegt ist, z. B.:

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

Wenn Azure Ihre Logik-App-Ressourcendefinition erstellt, erhält das identity-Objekt die folgenden principalId- und tenantId-Eigenschaften:

"identity": {
   "type": "SystemAssigned",
   "principalId": "<principal-ID>",
   "tenantId": "<Entra-tenant-ID>"
}
Eigenschaft (JSON) Wert BESCHREIBUNG
principalId < ID_des_Prinzipals> Der Globally Unique Identifier (GUID), den Microsoft Entra verwendet, um das Dienstprinzipal-Objekt für Ihre verwaltete Identität im Microsoft Entra Mandant zu verwalten. Diese GUID wird manchmal als "Objekt-ID" oder objectID.
tenantId < Microsoft-Entra-tenant-ID> Die GUID (Globally Unique Identifier), die den Microsoft Entra-Mandanten angibt, in dem die Logik-App nun Mitglied ist Im Microsoft Entra-Mandanten hat der Dienstprinzipal den gleichen Namen wie die Logik-App-Instanz.

Erstellen einer vom Benutzer zugewiesenen Identität (Portal)

Sie müssen die Identität als separate Azure-Ressource erstellen, bevor Sie die vom Benutzer zugewiesene Identität für eine Ressource der Verbrauchs- oder Standardlogik-App aktivieren können.

  1. Geben Sie im Suchfeld des Azure-Portals die Zeichenfolge managed identitiesein. Wählen Sie in der Ergebnisliste Verwaltete Identitäten aus.

    Screenshot des Azure-Portals mit ausgewählter Option „Verwaltete Identitäten“.

  2. Wählen Sie in der Symbolleiste der Seite Verwaltete Identitäten die Option Erstellen aus.

  3. Geben Sie beispielsweise die verwalteten Identitätsinformationen ein:

    Screenshot: Bereich „Erstellen einer benutzerseitig zugewiesenen verwalteten Identität“ mit Details zur verwalteten Identität.

    Eigenschaft Erforderlich Wert BESCHREIBUNG
    Abonnement Ja < Name des Azure-Abonnements> Der Name des Azure-Abonnements.
    Ressourcengruppe Ja < Name der Azure-Ressourcengruppe> Der Azure-Ressourcengruppenname. Erstellen Sie eine neue Gruppe, oder wählen Sie eine vorhandene Gruppe aus. In diesem Beispiel wird eine neue Gruppe mit dem Namen fabrikam-managed-identities-RGerstellt.
    Region Ja < Azure-Region> Die Azure-Region, in der die Informationen zu Ihrer Ressource gespeichert werden sollen. In diesem Beispiel wird West US verwendet.
    Name Ja < Name_Ihrer_benutzerseitig_zugewiesenen_Identität> Der Name für die benutzerseitig zugewiesene Identität. In diesem Beispiel wird Fabrikam-user-assigned-identity verwendet.
    Isolationsbereich Nein - None (Standard)
    - Region    		 Der effektive Gültigkeitsbereich für die verwaltete Identität.

  4. Wenn Sie fertig sind, wählen Sie Überprüfen + Erstellen aus.

    Nach Überprüfung dieser Informationen durch Azure erstellt Azure Ihre verwaltete Identität. Nun können Sie Ihrer Logik-App-Ressource die vom Benutzer zugewiesene Identität hinzufügen.

Hinzufügen einer vom Benutzer zugewiesenen Identität zur Logik-App (Portal)

Nachdem Sie die vom Benutzer zugewiesene Identität erstellt haben, fügen Sie die Identität zu Ihrer Consumption oder Standard Logic App Ressource hinzu.

  1. Öffnen Sie im Azure-Portal Ihre verbrauchsbasierte Logik-App-Ressource.

  2. Wählen Sie auf der Randleiste der Logik-App unter "Einstellungen" die Option "Identität" aus.

  3. Wählen Sie auf der Seite Identität die Option Benutzerseitig zugewiesen aus, und wählen Sie dann Hinzufügen aus.

    Ein Screenshot zeigt eine Consumption Logic App und die Seite Identität mit einer ausgewählten Option für Hinzufügen.

  4. Führen Sie im Bereich Benutzerseitig zugewiesene verwaltete Identität hinzufügen die folgenden Schritte aus:

    1. Wählen Sie in der Liste Abonnement auswählen Ihr Azure-Abonnement aus.

    2. Wählen Sie in der Liste verwalteter Identitäten die gewünschte vom Benutzer zugewiesene Identität aus.

      Um die Liste zu filtern, geben Sie im Suchfeld " Vom Benutzer zugewiesene verwaltete Identitäten " den Namen für die Identität oder Ressourcengruppe ein, z. B.:

      Screenshot einer Consumption Logic-App und der ausgewählten vom Benutzer zugewiesenen Identität.

    3. Wenn Sie fertig sind, wählen Sie "Hinzufügen" aus.

    Ihre Logik-App ist jetzt der benutzerseitig zugewiesenen Identität zugeordnet.

    Der Screenshot zeigt eine Consumption Logic App mit einer benutzerzugewiesenen Identität.

  5. Gewähren Sie der Identität Zugriff auf die geschützte Ressource.

Erstellen einer vom Benutzer zugewiesenen Identität (ARM-Vorlage)

Verwenden Sie eine ARM-Vorlage, um das Erstellen und Bereitstellen von Logik-App-Ressourcen zu automatisieren. Diese Vorlagen unterstützen benutzerseitig zugewiesene Identitäten für die Authentifizierung.

Im Abschnitt Ihrer Vorlage resources erfordert ihre Logik-App-Ressourcendefinition die folgenden Elemente:

  • Ein identity Objekt mit der type Eigenschaft, die auf UserAssigned festgelegt ist.
  • Ein untergeordnetes userAssignedIdentities Objekt, das die vom Benutzer zugewiesene Ressource und den Namen angibt.

Das folgende Beispiel zeigt eine Verbrauchs-Logik-App-Ressource und eine Workflowdefinition für eine HTTP-Anforderung PUT mit einem nichtparameterisierten identity Objekt. Die Antwort auf die PUT Anforderung und den nachfolgenden GET Vorgang enthält auch dieses identity Objekt.

Eine Ressource der Konsumptionslogik-App kann sowohl eine vom System zugewiesene Identität als auch mehrere vom Benutzer zugewiesene Identitäten aktiviert und definiert haben.

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

Wenn Ihre Vorlage die Ressourcendefinition der verwalteten Identität enthält, können Sie das identity Objekt parametrisieren. Das folgende Beispiel zeigt, wie das userAssignedIdentities untergeordnete Objekt auf eine userAssignedIdentityName Variable verweist, die Sie im Abschnitt Ihrer Vorlage variables definieren. Diese Variable verweist auf die Ressourcen-ID für Ihre benutzerseitig zugewiesene Identität.

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

Wenn die Vorlage Ihre Logik-App-Ressourcendefinition erstellt, enthält das identity-Objekt die folgenden principalId- und clientId-Eigenschaften:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<resource-ID>": {
            "principalId": "<principal-ID>",
            "clientId": "<client-ID>"
        }
    }
}
Eigenschaft (JSON) Wert BESCHREIBUNG
principalId < ID_des_Prinzipals> Die GUID (Globally Unique Identifier), die Microsoft Entra verwendet, um das Dienstprinzipalobjekt für Ihre verwaltete Identität im Microsoft Entra-Mandanten zu verwalten. Diese GUID wird manchmal als "Objekt-ID" oder objectID. Im Microsoft Entra-Mandanten hat der Dienstprinzipal denselben Namen wie die Logik-App-Instanz.
clientId < Client-ID> Die GUID (Globally Unique Identifier), die die Identität der Logik-App darstellt, und gibt die Identität an, die während Laufzeitaufrufen verwendet werden soll.

Weitere Informationen zu Azure Resource Manager-Vorlagen und verwalteten Identitäten für Azure-Funktionen finden Sie in der ARM-Vorlage – Azure Functions.

Gewähren Sie einer Identität Zugriff auf Ressourcen

Bevor Sie die verwaltete Identität für die Authentifizierung verwenden können, müssen Sie der Ziel-geschützten Azure-Ressource den Identitätszugriff gewähren. Die Art und Weise, wie Sie den Zugriff einrichten, kann sich je nach Zielressource unterscheiden, z. B.:

  • Azure rollenbasierte Zugriffssteuerung (RBAC)

    Einige Azure-Ressourcen, z. B. Speicherkonten, erfordern, dass Sie RBAC verwenden, um der Zielressource eine Rolle mit den erforderlichen Berechtigungen für Ihre Identität zuzuweisen.

    Um beispielsweise einer verwalteten Identität Zugriff auf ein Blob-Speicherkonto in Azure zu gewähren, müssen Sie Ihrer Identität die erforderliche Azure-Rolle für die Speicherressource des Kontos zuweisen.

    In diesem Abschnitt wird gezeigt, wie Sie eine Rolle mithilfe der Azure-Portal - und Azure Resource Manager-Vorlage (ARM-Vorlage) zuweisen.

    Informationen zu Azure PowerShell, Azure CLI und Azure REST-API finden Sie unter:

    Tool Dokumentation
    Azure PowerShell Hinzufügen der Rollenzuweisung
    Azure CLI Hinzufügen der Rollenzuweisung
    Azure-REST-API Hinzufügen der Rollenzuweisung

  • Zugriffsrichtlinie

    Andere Azure-Ressourcen, z. B. Schlüsseltresor, ermöglichen Ihnen auch das Erstellen einer Zugriffsrichtlinie für die Zielressource mit den erforderlichen Berechtigungen für Ihre Identität.

    Sie können beispielsweise eine Richtlinie für den Zugriff auf die Ressource Key Vault erstellen, um die erforderlichen Berechtigungen für Ihre verwaltete Identität zuzuweisen.

    In diesem Abschnitt wird gezeigt, wie Sie mithilfe des Azure-Portals eine Zugriffsrichtlinie erstellen.

    Informationen zu Ressourcen-Manager-Vorlagen, Azure PowerShell und Azure CLI finden Sie unter:

    Tool Dokumentation
    Azure Resource Manager-Vorlage (ARM-Vorlage) Key Vault-Zugriffsrichtlinien-Ressourcendefinition
    Azure PowerShell Zuweisen einer Key Vault-Zugriffsrichtlinie
    Azure CLI Zuweisen einer Key Vault-Zugriffsrichtlinie

Verwalteter Identitätszugriff auf Ressourcen höherer Ebene

Wenn eine verwaltete Identität Zugriff auf eine Ressource im selben Abonnement hat, kann die Identität nur auf diese Ressource zugreifen, nicht auf andere Ressourcen in der übergeordneten Hierarchie dieser Ressource. Im Workflow-Designer müssen Sie bei einigen Triggern und Aktionen zunächst ein Abonnement oder eine Ressourcengruppe auswählen, bevor Sie die Zielressource auswählen können. Wenn die Identität keinen Zugriff auf diese Ressourcen auf höherer Ebene hat, zeigt der Designer die Zielressource nicht an.

Um dieses Problem zu beheben, gewähren Sie den Identitätszugriff auf jede Ressource auf höherer Ebene, die Sie zuerst auswählen müssen.

In anderen Fällen benötigt die Identität auch Zugriff auf die Ressource, in der Sie die Identität aktiviert haben. Angenommen, Sie haben eine Workflowaktion, die die Anwendungseinstellungen in der übergeordneten Logik-App des Workflows aktualisiert. Wenn die Aktion eine verwaltete Identität für den Zugriff auf diese Einstellungen verwendet, geben Sie der Identität Zugriff auf die übergeordnete Logic App.

Zuweisen des rollenbasierten Zugriffs auf eine verwaltete Identität (Portal)

Führen Sie für Azure-Ressourcen, für die Sie eine Rolle für Ihre verwaltete Identität zuweisen müssen, die folgenden Schritte aus:

  1. Öffnen Sie im Azure-Portal die Ressource, auf die die Identität Zugriff benötigt.

    In diesem Beispiel wird ein Speicherkonto als Azure-Zielressource verwendet.

  2. Wählen Sie auf der Ressourcen-Randleiste access control (IAM) aus.

  3. Wählen Sie auf der Symbolleiste für die Zugriffssteuerung (IAM) die Option"Rollenzuweisung hinzufügen"> aus.

    Hinweis

    Wenn Sie keine Rollenzuweisung hinzufügen können, verfügen Sie nicht über die Berechtigungen zum Zuweisen von Rollen. Sie benötigen Microsoft Entra-Administratorberechtigungen , damit Sie verwalteten Identitäten Rollen zuweisen können.

  4. Führen Sie die folgenden Schritte aus, um Ihrer verwalteten Identität die erforderliche Rolle zuzuweisen:

    1. Suchen Sie auf der Registerkarte " Rolle " die integrierte Microsoft Entra-Rolle , die Ihrer Identität den erforderlichen Zugriff auf die aktuelle Ressource gewährt, und wählen Sie dann "Weiter" aus.

      In diesem Beispiel wird die Rolle namens "Storage Blob Data Contributor" ausgewählt. Diese Rolle bietet Schreibzugriff auf BLOB-Inhalte in einem Azure-Speichercontainer.

      Weitere Informationen finden Sie unter Rollen, die auf BLOB-Inhalte in einem Azure-Speichercontainer zugreifen.

    2. Führen Sie auf der Registerkarte " Mitglieder " die folgenden Schritte aus, um die verwaltete Identität auszuwählen:

      1. Wählen Sie unter Zugriff zuweisen zu die Option Verwaltete Identität aus.

      2. Wählen Sie Mitglieder hinzufügen und dann + Mitglieder auswählen.

      3. Wählen Sie im Bereich "Verwaltete Identitäten auswählen " Ihr Azure-Abonnement aus.

      4. Wählen Sie basierend auf Ihrer verwalteten Identität den Typ "Verwaltete Identität " und dann Ihre verwaltete Identität aus.

        Typ der verwalteten Identität BESCHREIBUNG
        Benutzerseitig zugewiesene verwaltete Identität Anzeigen und Auswählen einer aktivierten vom Benutzer zugewiesenen verwalteten Identität in einer beliebigen Azure-Ressource.
        Alle vom System zugewiesenen verwalteten Identitäten Zeigen Sie eine aktivierte vom System zugewiesene verwaltete Identität in einer beliebigen Azure-Ressource an, und wählen Sie sie aus.
        Logik-App Sie können eine aktivierte verwaltete Identität nur für Ressourcen der Logic Apps anzeigen und auswählen.

      5. Wenn Sie fertig sind, wählen Sie Auswählen aus.

    Weitere Informationen findest du unter:

  5. Authentifizieren Sie Den Trigger oder die Aktion mithilfe der verwalteten Identität.

Erstellen einer Zugriffsrichtlinie im Azure-Portal

Führen Sie für Azure-Ressourcen, in denen Sie eine Zugriffsrichtlinie für Ihre verwaltete Identität erstellen möchten, die folgenden Schritte aus:

  1. Öffnen Sie im Azure-Portal die Ressource, auf die die Identität Zugriff benötigt.

    In diesem Beispiel wird ein Schlüsseltresor als Azure-Zielressource verwendet.

  2. Wählen Sie auf der Ressourcen-Randleiste Access-Richtlinien aus.

    Hinweis

    Wenn die Ressource nicht über die Access-Richtlinienoption verfügt, weisen Sie stattdessen eine Rolle zu.

  3. Wählen Sie auf der Seitensymbolleiste " Erstellen" aus, um den Bereich "Zugriffsrichtlinien erstellen" zu öffnen.

    Screenshot des Azure-Portals und eines Beispiels für einen Schlüsseltresor mit geöffnetem Bereich namens

  4. Wählen Sie auf der Registerkarte "Berechtigungen " die Berechtigungen aus, die die Identität für den Zugriff auf die Zielressource benötigt.

    Um beispielsweise die Identität mit der Aktion „Geheimnisse auflisten“ des verwalteten Azure Key Vault-Connectors zu verwenden, benötigt die Identität Auflisten-Berechtigungen. Wählen Sie in diesem Szenario in der Spalte "Geheime Berechtigungen " die Option "Liste" aus.

    Screenshot der Registerkarte

  5. Klicken Sie abschließend auf Weiter.

  6. Wählen Sie auf der Registerkarte "Prinzipal " die verwaltete Identität aus.

    In diesem Beispiel wird eine vom Benutzer zugewiesene Identität ausgewählt.

  7. Überspringen Sie den Schritt optionalen Schritt Anwendung, wählen Sie Weiter aus, und schließen Sie die Erstellung der Zugriffsrichtlinie ab.

  8. Authentifizieren Sie Den Trigger oder die Aktion mithilfe der verwalteten Identität.

Authentifizieren des Zugriffs mithilfe der verwalteten Identität

In diesem Abschnitt wird gezeigt, wie Sie eine verwaltete Identität verwenden, um den Zugriff für einen Workflowtrigger oder eine Aktion zu authentifizieren, die die verwaltete Identitätsauthentifizierung unterstützt. Das Beispiel setzt fort, von wo aus Sie den Zugriff für eine verwaltete Identität mithilfe von RBAC und einem Azure Storage-Konto einrichten. Obwohl Ihre Ziel-Azure-Ressource möglicherweise unterschiedlich ist, sind die allgemeinen Schritte meist ähnlich.

Wichtig

Für eine Azure-Funktion, für die die systemseitig zugewiesene Identität verwendet werden soll, müssen Sie zunächst die Authentifizierung für Azure-Funktionen aktivieren.

Die folgenden Schritte zeigen, wie Sie die verwaltete Identität mithilfe des Azure-Portals verwenden. Informationen zur Verwendung der verwalteten Identität in der zugrunde liegenden JSON-Definition mithilfe des Code-Editors finden Sie unter Verwaltete Identitätsauthentifizierung.

  1. Öffnen Sie im Azure-Portal Ihre Logik-App-Ressource (Verbrauch).

  2. Fügen Sie den Trigger oder die Aktion hinzu, der verwaltete Identitäten unterstützt, sofern noch nicht geschehen.

  3. Führen Sie beim Trigger oder bei der Aktion die folgenden Schritte aus:

    • Integrierte Vorgänge

      In diesen Schritten wird die HTTP-Aktion als Beispiel verwendet.

      1. Wählen Sie in der Liste "Erweiterte Parameter" den Authentifizierungsparameter aus.

        Screenshot eines Verbrauchsworkflows mit integrierter HTTP-Aktion und geöffneter Liste mit dem Namen

        Sowohl der Authentifizierungsparameter als auch die Authentifizierungstypliste werden angezeigt, z. B.:

        Screenshot des Abschnitts

      2. Wählen Sie in der Liste " Authentifizierungstyp " die Option "Verwaltete Identität" aus.

        Screenshot eines Workflows mit einer integrierten Aktion, geöffneter Authentifizierungstypliste und ausgewählter Option für verwaltete Identität.

        Im Abschnitt Authentifizierung werden nun die folgenden Optionen angezeigt:

        Parameter BESCHREIBUNG
        Verwaltete Identität Die zu verwendende verwaltete Identität.
        Publikum Wird für bestimmte Trigger und Aktionen angezeigt, damit Sie die Ressourcen-ID für die Azure-Zielressource oder den Dienst festlegen können.

        Standardmäßig verwendet der Parameter "Audience " die https://management.azure.com/ Ressourcen-ID, bei der es sich um die Ressourcen-ID für Azure Resource Manager handelt.

      3. Wählen Sie in der Liste "Verwaltete Identität " die gewünschte Identität aus, z. B.:

        Screenshot des Abschnitts „Authentifizierung“ mit Authentifizierungstypliste und Zielgruppeneigenschaft.

        Hinweis

        Standardmäßig ist die vom System zugewiesene verwaltete Identität die ausgewählte Option, auch wenn Sie keine verwalteten Identitäten aktivieren. Um jedoch die verwaltete Identität erfolgreich zu verwenden, müssen Sie diese Identität zuerst in Ihrer Logik-App aktivieren. Verbrauchslogik-Apps aktivieren die Systemidentität nicht automatisch im Gegensatz zu Standardlogik-Apps.

      Weitere Informationen finden Sie im Beispiel: Authentifizieren eines vordefinierten Triggers oder einer Aktion über eine verwaltete Identität.

    • Verwaltete Connectorvorgänge

      1. Wählen Sie im Bereich "Verbindung erstellen " in der Authentifizierungsliste die Option "Verwaltete Identität" aus, z. B.:

        Screenshot, der den Verbrauchsworkflow mit der Azure Resource Manager-Aktion und der ausgewählten Option für „Verwaltete Identität“ zeigt.

      2. Geben Sie im nächsten Bereich für den Verbindungsnamen einen Namen ein, der für die Verbindung verwendet werden soll.

      3. Wählen Sie basierend auf Ihrem Connector eine der folgenden Optionen aus:

        • Einfache Authentifizierung: Diese Connectors unterstützen nur einen Authentifizierungstyp, in diesem Fall eine verwaltete Identität.

          Die folgenden Schritte verwenden eine Azure Resource-Aktion als Beispiel:

          1. Wählen Sie in der Liste Verwaltete Identität die aktuell aktivierte verwaltet Identität aus.

          2. Wählen Sie "Neu erstellen" aus.

        • Mehrfachauthentifizierung: Diese Connectors unterstützen mehrere Authentifizierungstypen, aber Sie können jeweils nur einen Typ auswählen.

          Die folgenden Schritte verwenden eine Azure Blob Storage-Aktion als Beispiel:

          1. Wählen Sie in der Liste Authentifizierungstyp die Option Verwaltete Logic Apps-Identität aus.

            Screenshot: Verbrauchsworkflow, Feld zum Erstellen einer Verbindung und ausgewählte Option für verwaltete Logik-Apps-Identität.

          2. Wählen Sie "Neu erstellen" aus.

          Weitere Informationen finden Sie im Beispiel: Authentifizieren eines Triggers mit verwaltetem Connector oder einer Aktion über eine verwaltete Identität.

Beispiel: Authentifizieren eines vordefinierten Triggers oder einer Aktion über eine verwaltete Identität

Der integrierte HTTP-Trigger oder die integrierte Aktion kann die vom System zugewiesene Identität verwenden, die Sie in Ihrer Logik-App-Ressource aktivieren. Im Allgemeinen verwendet der HTTP-Trigger oder die Aktion die folgenden Eigenschaften, um die Ressource oder Entität anzugeben, auf die Sie zugreifen möchten:

Eigenschaft Erforderlich BESCHREIBUNG
Methode Ja Die HTTP-Methode für den Vorgang, den Sie ausführen möchten
URI Ja Die Endpunkt-URL für den Zugriff auf die Azure-Zielressource oder Azure-Zielentität. Die URI-Syntax enthält normalerweise die Ressourcen-ID für die Azure-Zielressource oder den Azure-Zieldienst.
Headers Nein Alle Headerwerte, die Sie in der ausgehenden Anforderung einfügen müssen oder möchten, z. B. den Inhaltstyp
Abfragen Nein Alle Abfrageparameter, die Sie in die Anforderung einschließen müssen oder möchten – beispielsweise Abfrageparameter für einen bestimmten Vorgang oder für die API-Version des Vorgangs, den Sie ausführen möchten.
Authentifizierung Ja Der Authentifizierungstyp, der zum Authentifizieren des Zugriffs auf die Zielressource oder den Zieldienst verwendet werden soll

Als konkretes Beispiel wird angenommen, dass Sie den Snapshot Blob-Vorgang für ein Blob in dem Azure Storage-Konto ausführen möchten, in dem Sie zuvor den Zugriff für die Identität eingerichtet haben. Jedoch unterstützt der Azure Blob Storage-Connector diesen Vorgang derzeit nicht. Stattdessen können Sie diesen Vorgang mithilfe der HTTP-Aktion oder mit einem anderen REST-API-Vorgang des Blob-Diensts ausführen.

Wichtig

Stellen Sie für den Zugriff auf Azure-Speicherkonten hinter Firewalls mithilfe des Azure Blob Storage-Connectors und verwalteter Identitäten sicher, dass Sie Ihr Speicherkonto auch mit der Ausnahme, die den Zugriff durch vertrauenswürdige Microsoft-Dienste zulässt, einrichten.

Zum Ausführen des Snapshot Blob-Vorgangs gibt die HTTP-Aktion die folgenden Eigenschaften an:

Eigenschaft Erforderlich Beispielwert BESCHREIBUNG
URI Ja https://<storage-account-name>/<folder-name>/{name} Die Ressourcen-ID für eine Azure Blob Storage-Datei in der Azure Global (public) Umgebung, die diese Syntax verwendet.
Methode Ja PUT Die HTTP-Methode, die vom Snapshot Blob-Vorgang verwendet wird.
Headers Für Azure Storage x-ms-blob-type = BlockBlob

x-ms-version = 2024-05-05

x-ms-date = formatDateTime(utcNow(),'r')		 Die Headerwerte x-ms-blob-type, x-ms-version und x-ms-date, die für Azure Storage-Vorgänge erforderlich sind.

Wichtig: In ausgehenden HTTP-Trigger - und Aktionsanforderungen für Azure Storage erfordert der Header die x-ms-version Eigenschaft und die API-Version für den Vorgang, den Sie ausführen möchten. Der x-ms-date Wert muss das aktuelle Datum sein. Andernfalls tritt bei Ihrem Workflow ein 403 FORBIDDEN-Fehler auf. Um das aktuelle Datum im erforderlichen Format abzurufen, können Sie den Ausdruck im Beispielwert verwenden.

Weitere Informationen finden Sie unter:

- Anforderungsheader: Momentaufnahmeblob
- Versionsverwaltung für Azure Storage-Dienste
Abfragen Nur für den Vorgang für den Momentaufnahmeblob comp = snapshot Der Name und der Wert des Abfrageparameters für den Vorgang.

  1. Fügen Sie im Workflow-Designer alle gewünschten Trigger hinzu, und fügen Sie dann die HTTP-Aktion hinzu.

    Das folgende Beispiel zeigt eine BEISPIEL-HTTP-Aktion mit allen zuvor beschriebenen Eigenschaftswerten, die für den Snapshot Blob-Vorgang verwendet werden sollen:

    Screenshot: Azure-Portal, Verbrauchsworkflow und HTTP-Aktion, die für den Zugriff auf Ressourcen eingerichtet ist.

  2. Wählen Sie in der HTTP-Aktion in der Liste "Erweiterte Parameter" die Option "Authentifizierung" aus.

    Screenshot des Verbrauchsworkflows mit HTTP-Aktion und geöffneter Liste „Erweiterte Parameter“ mit ausgewählter Eigenschaft „Authentifizierung“.

    Der Abschnitt "Authentifizierung " wird in Ihrer HTTP-Aktion angezeigt.

  3. Wählen Sie in der Liste " Authentifizierungstyp " die Option "Verwaltete Identität" aus.

    Screenshot: Verbrauchsworkflow, HTTP-Aktion und Eigenschaft „Authentifizierungstyp“ mit ausgewählter Option für „Verwaltete Identität“.

  4. Wählen Sie in der Liste verwalteter Identitäten die verfügbaren Optionen basierend auf Ihrem Szenario aus.

    • Wenn Sie die systemseitig zugewiesene Identität eingerichtet haben, wählen Sie Systemseitig zugewiesene verwaltete Identität aus.

      Ein Screenshot zeigt den Workflow Verbrauch, die HTTP-Aktion und die Eigenschaft Verwaltete Identität mit der ausgewählten Option für die vom System zugewiesene verwaltete Identität.

    • Wenn Sie die benutzerseitig zugewiesene Identität einrichten, wählen Sie diese Identität aus.

      Ein Screenshot zeigt den Workflow Verbrauch, die HTTP-Aktion und die Eigenschaft Verwaltete Identität mit der ausgewählten vom Benutzer zugewiesenen Identität.

    In diesem Beispiel wird weiterhin die Systemseitig zugewiesene verwaltete Identität verwendet.

  5. Einige Trigger und Aktionen zeigen den Parameter "Audience " an, damit Sie die Ressourcen-ID für die Azure-Zielressource oder den Zieldienst eingeben können.

    Wenn Sie beispielsweise den Zugriff auf eine Key Vault-Ressource in der globalen Azure-Cloud authentifizieren möchten, legen Sie den Parameter "Audience " auf genau die folgende Ressourcen-ID fest: https://vault.azure.net

    Andernfalls verwendet der Parameter "Audience " standardmäßig die https://management.azure.com/ Ressourcen-ID, bei der es sich um die Ressourcen-ID für Azure Resource Manager handelt.

    Wichtig

    Die Zielressourcen-ID muss exakt mit dem Von Microsoft Entra-ID erwarteten Wert übereinstimmen . Andernfalls erhalten Sie möglicherweise entweder einen 400 Fehlerhafte Anfrage oder einen 401 Nicht autorisiert Fehler. Wenn die Ressourcen-ID nachfolgende Schrägstriche enthält, berücksichtigen Sie diese. Wenn nicht, schließen Sie sie nicht ein.

    Die Ressourcen-ID für alle Azure Blob Storage-Konten erfordert z. B. einen nachgestellten Schrägstrich. Allerdings erfordert die Ressourcen-ID für ein bestimmtes Speicherkonto keinen nachgestellten Schrägstrich. Hier finden Sie die Ressourcen-IDs für die Azure-Dienste, die die Microsoft Entra ID-Authentifizierung unterstützen.

    Im folgenden Beispiel wird der Parameter Audience auf https://storage.azure.com/ gesetzt. Dieser Wert bedeutet, dass die Zugriffstoken für die Authentifizierung für alle Speicherkonten gültig sind. Geben Sie für ein bestimmtes Speicherkonto die Stammdienst-URL an. https://<your-storage-account>.blob.core.windows.net

    Screenshot: Verbrauchsworkflow und HTTP-Aktion mit der Eigenschaft „Audience“, die auf die Zielressourcen-ID festgelegt ist.

    Weitere Informationen findest du unter:

  6. Fahren Sie mit dem Erstellen des Workflows basierend auf Ihrem Szenario fort.

Beispiel: Authentifizieren des Triggers oder einer Aktion des verwalteten Connectors mithilfe einer verwalteten Identität

Der verwaltete Azure Resource Manager-Connector verfügt über eine Aktion namens "Ressource lesen ", die die verwaltete Identität verwenden kann, die Sie für Ihre Logik-App-Ressource aktivieren. Dieses Beispiel zeigt Ihnen die Verwendung der systemseitig zugewiesenen verwalteten Identität mit einem verwalteten Connector.

  1. Fügen Sie im Workflow-Designer die Azure Resource Manager-Aktion namens Ressource lesenhinzu.

  2. Wählen Sie im Bereich "Verbindung erstellen " in der Liste "Authentifizierung " die Option "Verwaltete Identität" und dann " Anmelden" aus.

    Hinweis

    In einigen Connectors zeigt die Authentifizierungstyp-Liste stattdessen Managed Identity von Logic Apps an. Wenn in Ihrem Szenario diese Option angezeigt wird, wählen Sie diese Option aus.

    Screenshot: Verbrauchsworkflow mit der Azure Resource Manager-Aktion, geöffneter Liste „Authentifizierung“ und der ausgewählten Option für „Verwaltete Identität“.

  3. Geben Sie einen Namen für die Verbindung ein, und wählen Sie die gewünschte verwaltete Identität aus.

    Wenn Sie die systemseitig zugewiesene Identität aktiviert haben, wählt die Liste Verwaltete Identität automatisch Systemseitig zugewiesene verwaltete Identität aus. Wenn Sie stattdessen eine benutzerseitig zugewiesene Identität aktiviert haben, wählt die Liste automatisch die benutzerseitig zugewiesene Identität aus.

    In diesem Beispiel ist die systemseitig zugewiesene verwaltete Identität die einzige verfügbare Auswahl.

    Screenshot: Verbrauchsworkflow und Azure Resource Manager-Aktion mit eingegebenem Verbindungsnamen und Auswahl von „Systemseitig zugewiesene verwaltete Identität“.

    Hinweis

    Wenn Sie die verwaltete Identität nicht aktivieren, wenn Sie versuchen, die Verbindung zu erstellen oder zu ändern, oder wenn Sie die verwaltete Identität entfernen, während eine verwaltete Identität noch vorhanden ist, erhalten Sie eine Fehlermeldung, die besagt, dass Sie die Identität aktivieren und Zugriff auf die Zielressource gewähren müssen.

  4. Wählen Sie abschließend Neu erstellen aus.

    Nachdem Sie die Verbindung erstellt haben, kann der Designer mithilfe der verwalteten Identitätsauthentifizierung alle dynamischen Werte, Inhalte oder Schemas abrufen.

  5. Fahren Sie mit dem Erstellen des Workflows basierend auf Ihrem Szenario fort.

Verbindungen mit verwalteten Identitäten in Logik-App-Ressourcendefinitionen

Ein verwalteter Identitätsauthentifizierter Verbindungstyp ist ein spezieller Verbindungstyp, der nur mit einer verwalteten Identität funktioniert. Zur Laufzeit des Workflows verwendet die Verbindung die verwaltete Identität, die für die Logic-App-Ressource aktiviert ist. Azure Logic Apps überprüft, ob verwaltete Connectorvorgänge im Workflow die verwaltete Identität verwenden und ob alle erforderlichen Berechtigungen vorhanden sind, um die verwaltete Identität für den Zugriff auf die entsprechenden Zielressourcen zu verwenden. Wenn diese Überprüfung erfolgreich bestanden wurde, ruft Azure Logic Apps das Microsoft Entra-Token ab, das der verwalteten Identität zugeordnet ist, verwendet diese Identität, um den Zugriff auf die Azure-Zielressourcen zu authentifizieren und die entsprechenden Vorgänge im Workflow auszuführen.

In einer Ressourcenressource der Verbrauchslogik-App speichern Sie die Verbindungskonfiguration im Objekt der Ressourcendefinition parameters . Dieses Objekt enthält das $connections Objekt, das Zeiger auf die Ressourcen-ID der Verbindung zusammen mit der Ressourcen-ID der verwalteten Identität enthält, wenn Sie die vom Benutzer zugewiesene Identität aktivieren.

Das folgende Beispiel zeigt das parameters Objekt, wenn die vom System zugewiesene Identität in einer Logik-App aktiviert ist:

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

Das folgende Beispiel zeigt das parameters Objekt, wenn die vom Benutzer zugewiesene verwaltete Identität in einer Logik-App aktiviert ist:

"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-Vorlage für API-Verbindungen und verwaltete Identitäten

Wenn Sie eine ARM-Vorlage zum Automatisieren der Bereitstellung verwenden und Ihr Workflow eine API-Verbindung enthält, die von einem verwalteten Connector erstellt wurde und eine verwaltete Identität verwendet, müssen Sie einen zusätzlichen Schritt ausführen.

In einer ARM-Vorlage unterscheidet sich die zugrunde liegende Connectorressourcendefinition je nachdem, ob Sie eine Verbrauchs- oder Standardlogik-App-Ressource verwenden und ob der Connector Optionen für die Einzelauthentifizierung oder multiauthentifizierung anzeigt.

Die folgenden Beispiele gelten für Ressourcen der Verbrauchslogik-App. Sie zeigen, wie sich die zugrunde liegende Connectorressourcendefinition zwischen einem Einzelauthentifizierungsconnector und einem Multiauthentication-Connector unterscheidet.

Einfache Authentifizierung

Dieses Beispiel zeigt die zugrunde liegende Definition der Verbindungsressource für eine Connectoraktion, die nur einen Authentifizierungstyp unterstützt und eine verwaltete Identität in einem Verbrauchslogik-App-Workflow verwendet. Die Definition enthält die folgenden Attribute:

  • Die kind-Eigenschaft ist auf V1 für einen Verbrauchsworkflow festgelegt.

  • Die parameterValueType-Eigenschaft ist auf Alternative festgelegt.

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

Mehrere Authentifizierungsmethoden

Dieses Beispiel zeigt die zugrunde liegende Definition der Verbindungsressource für eine Connectoraktion, die mehrere Authentifizierungstypen unterstützt und eine verwaltete Identität in einem Verbrauchslogik-App-Workflow verwendet. Die Definition enthält die folgenden Attribute:

  • Die Eigenschaft kind ist auf V1 für einen Verbrauchs-Workflow festgelegt.

  • Das parameterValueSet-Objekt umfasst eine name-Eigenschaft, die auf festgelegt managedIdentityAuth ist, sowie eine values-Eigenschaft, die auf ein leeres Objekt festgelegt ist.

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

Einrichten des erweiterten Steuerelements für die API-Verbindungsauthentifizierung

Wenn Ihr Standardlogik-App-Workflow eine API-Verbindung verwendet, die ein verwalteter Connector erstellt, verwendet Azure Logic Apps zwei Verbindungen, um mit der Zielressource zu kommunizieren, z. B. Ihrem E-Mail-Konto oder Ihrem Schlüsseltresor:

Konzeptdiagramm: Erste Verbindung mit Authentifizierung zwischen Logik-App und Tokenspeicher und zweite Verbindung zwischen Tokenspeicher und Zielressource.

  • Verbindung 1 wird mit Authentifizierung für den internen Tokenspeicher eingerichtet.

  • Verbindung 2 wird mit Authentifizierung für die Zielressource eingerichtet.

Wenn ein Workflow der Verbrauchslogik-App jedoch eine API-Verbindung verwendet, können Sie keine Verbindung #1 anzeigen oder einrichten. Wenn Sie eine Standardlogik-App-Ressource verwenden, erhalten Sie mehr Kontrolle über Ihre Logik-App und -Workflows. Standardmäßig verwendet Die Verbindung Nr. 1 die vom System zugewiesene Identität.

Wenn Für Ihr Szenario eine genauere Kontrolle über die Authentifizierung von API-Verbindungen erforderlich ist, ändern Sie die Authentifizierung für Die Verbindung Nr. 1 von der Standardidentität des Systems auf eine beliebige vom Benutzer zugewiesene Identität, die Sie Ihrer Logik-App hinzufügen. Diese Authentifizierung gilt für jede API-Verbindung, sodass Sie vom System zugewiesene und vom Benutzer zugewiesene Identitäten verschiedene Verbindungen übergreifend für dieselbe Zielressource kombinieren können.

In der connections.json-Datei Ihrer Standardlogik-App, die Informationen zu jeder API-Verbindung speichert, verfügt jede Verbindungsdefinition über zwei authentication Objekte, z. B.:

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

  • Das erste authentication Objekt ist der Verbindung #1 zugeordnet.

    Dieses Objekt beschreibt die Authentifizierung, die für die Kommunikation mit dem internen Tokenspeicher verwendet wird. In der Vergangenheit wurde das type Eigenschaftsset für eine App, die auf Azure bereitgestellt wird und keine konfigurierbaren Optionen hat, immer auf ManagedServiceIdentity festgelegt.

  • Das zweite authentication Objekt ist der Verbindung #2 zugeordnet.

    Dieses Objekt beschreibt die Authentifizierung, die für die Kommunikation mit der Zielressource verwendet wird, und kann je nach dem Authentifizierungstyp variieren, den Sie für diese Verbindung auswählen.

Warum sollte die Authentifizierung für den Tokenspeicher geändert werden?

In einigen Szenarien möchten Sie möglicherweise dieselbe API-Verbindung über mehrere Logik-App-Ressourcen hinweg freigeben und verwenden, sie möchten jedoch nicht die vom System zugewiesene Identität für jede Logik-App-Ressource zur Zugriffsrichtlinie der Zielressource hinzufügen.

In anderen Szenarien möchten Sie die vom System zugewiesene Identität in Ihrer Logik-App möglicherweise nicht einrichten. Um stattdessen eine vom Benutzer zugewiesene Identität zu verwenden, können Sie die Authentifizierung in eine vom Benutzer zugewiesene Identität ändern und die vom System zugewiesene Identität vollständig deaktivieren.

Ändern der Authentifizierung für den Tokenspeicher

  1. Öffnen Sie im Azure-Portal Ihre Standard-Logik-App-Ressource.

  2. Wählen Sie auf der Ressourcen-Randleiste unter "Workflows" "Verbindungen" aus.

  3. Wählen Sie im Bereich Verbindungen die Option JSON-Ansicht aus.

    Screenshot: Azure-Portal, Standard-Logik-App-Ressource, Bereich „Verbindungen“ mit ausgewählter Option „JSON-Ansicht“.

  4. Suchen Sie im JSON-Editor das managedApiConnections Objekt. Dieses Objekt enthält die API-Verbindungen über alle Workflows in Ihrer Logik-App-Ressource.

  5. Suchen Sie die Verbindung, der Sie eine vom Benutzer zugewiesene verwaltete Identität hinzufügen möchten.

    Angenommen, Ihr Workflow verfügt über eine Azure Key Vault-Verbindung:

    "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. Führen Sie in der Verbindungsdefinition die folgenden Schritte aus:

    1. Suchen Sie das erste authentication Objekt. Wenn in diesem identity Objekt keine authentication Eigenschaft vorhanden ist, verwendet die Logik-App implizit die vom System zugewiesene Identität.

    2. Fügen Sie mithilfe des Beispiels in diesem Schritt eine identity-Eigenschaft hinzu.

    3. Legen Sie den Eigenschaftswert auf die Ressourcen-ID für die vom Benutzer zugewiesene Identität fest.

    "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. Wechseln Sie im Azure-Portal zur Zielressource, und gewähren Sie basierend auf den Anforderungen der Zielressource Zugriff auf die vom Benutzer zugewiesene verwaltete Identität.

    Fügen Sie beispielsweise für Azure Key Vault die Identität den Zugriffsrichtlinien des Schlüsseltresors hinzu. Weisen Sie für Azure Blob Storage die erforderliche Rolle für die Identität dem Speicherkonto zu.

Deaktivieren von verwalteten Identitäten

Führen Sie die folgenden Schritte aus, um die Verwendung der verwalteten Identität für die Authentifizierung zu beenden:

  1. Entfernen Sie den Zugriff der Identität auf die Zielressource.

  2. Deaktivieren Sie in Ihrer Logik-App-Ressource die vom System zugewiesene Identität, oder entfernen Sie die vom Benutzer zugewiesene Identität.

Wenn Sie die verwaltete Identität für Ihre Logik-App-Ressource deaktivieren, entfernen Sie die Funktion für diese Identität, um den Zugriff auf Azure-Ressourcen anzufordern, auf die die Identität Zugriff hatte.

Hinweis

Wenn Sie die vom System zugewiesene Identität deaktivieren, funktionieren alle Verbindungen, die die Identität in den Workflows der Logik-App verwenden, zur Laufzeit nicht mehr, auch wenn Sie die Identität sofort wieder aktivieren.

Dieses Verhalten tritt auf, da durch das Deaktivieren der Identität die Objekt-ID gelöscht wird. Jedes Mal, wenn Sie die Identität aktivieren, generiert Azure die Identität mit einer anderen und eindeutigen Objekt-ID. Um dieses Problem zu beheben, erstellen Sie die Verbindungen neu, damit sie die aktuelle Objekt-ID für die aktuelle vom System zugewiesene Identität verwenden.

Vermeiden Sie das Deaktivieren der vom System zugewiesenen Identität so weit wie möglich. Um den Zugriff der Identität auf Azure-Ressourcen zu entfernen, entfernen Sie die Rollenzuweisung der Identität aus der Zielressource. Wenn Sie die Logik-App-Ressource löschen, wird in Azure die verwaltete Identität automatisch aus Microsoft Entra ID entfernt.

In den folgenden Abschnitten wird gezeigt, wie Sie die verwaltete Identität mithilfe der Azure-Portal - und Azure Resource Manager-Vorlage (ARM-Vorlage) deaktivieren. Informationen zu Azure PowerShell, Azure CLI und Azure REST-API finden Sie unter:

Tool Dokumentation
Azure PowerShell 1. Entfernen von Rollenzuweisungen.
2. Löschen von benutzerseitig zugewiesenen Identitäten.
Azure CLI 1. Entfernen von Rollenzuweisungen.
2. Löschen von benutzerseitig zugewiesenen Identitäten.
Azure-REST-API 1. Entfernen von Rollenzuweisungen.
2. Löschen von benutzerseitig zugewiesenen Identitäten.

Weitere Informationen finden Sie unter Entfernen von Azure-Rollenzuweisungen.

Deaktivieren der verwalteten Identität im Azure-Portal

Um den Zugriff für die verwaltete Identität zu entfernen, entfernen Sie die Rollenzuweisung der Identität aus der Zielressource, und deaktivieren Sie dann die verwaltete Identität.

Entfernen von Rollenzuweisungen

Mit den folgenden Schritten wird der Zugriff auf die Zielressource aus der verwalteten Identität entfernt:

  1. Navigieren Sie im Azure-Portal zu der Azure-Zielressource, für die Sie den Zugriff für die verwaltete Identität aufheben möchten.

  2. Wählen Sie auf der Zielressourcen-Randleiste access control (IAM) aus. Wählen Sie auf der Symbolleiste die Option Rollenzuweisungen aus.

  3. Wählen Sie in der Liste der Rollen die verwalteten Identitäten aus, die Sie entfernen möchten. Wählen Sie auf der Symbolleiste die Option Entfernen aus.

    Hinweis

    Wenn die Option Entfernen deaktiviert ist, verfügen Sie wahrscheinlich nicht über die erforderlichen Berechtigungen. Weitere Informationen zu den Berechtigungen, mit denen Sie Rollen für Ressourcen verwalten können, finden Sie unter Berechtigungen der Administratorrolle in Microsoft Entra ID.

Deaktivieren einer verwalteten Identität für die Logik-App-Ressource

  1. Öffnen Sie Ihre Logik-App-Ressource im Azure-Portal.

  2. Wählen Sie auf der Randleiste der Logik-App unter "Einstellungen" die Option "Identität" aus, und führen Sie dann die Schritte für Ihre Identität aus:

    • Wählen Sie Systemseitig zugewiesen>Aus>Speichern aus. Wenn Sie von Azure zur Bestätigung aufgefordert werden, wählen Sie Ja aus.

    • Wählen Sie Vom Benutzer zugewiesen, die verwaltete Identität und dann Entfernen aus. Wenn Sie von Azure zur Bestätigung aufgefordert werden, wählen Sie Ja aus.

Deaktivieren einer verwalteten Identität in einer ARM-Vorlage

Wenn Sie die verwaltete Identität der Logik-App mithilfe einer ARM-Vorlage erstellt haben, legen Sie die untergeordnete identity-Eigenschaft des type-Objekts auf None fest.

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

Verwandte Inhalte

  • Last updated on