مصادقة الوصول والاتصالات إلى موارد Azure باستخدام الهويات المدارة في Azure Logic Apps

مقالة
12/09/2023

ينطبق على: Azure Logic Apps (الاستهلاك + قياسي)

عند استخدام هوية مدارة لمصادقة الوصول أو الاتصالات إلى الموارد المحمية من Microsoft Entra من سير عمل التطبيق المنطقي، لا يتعين عليك توفير بيانات الاعتماد أو الأسرار أو الرموز المميزة ل Microsoft Entra. في Azure Logic Apps، تدعم بعض عمليات الموصل استخدام هوية مدارة عندما تضطر إلى مصادقة الوصول إلى الموارد المحمية بواسطة معرف Microsoft Entra. يدير Azure هذه الهوية ويساعد على الحفاظ على أمان معلومات المصادقة لأنه ليس عليك إدارة هذه المعلومات الحساسة. لمزيد من المعلومات، راجع ما الهويات المدارة لموارد Azure؟.

تدعم Azure Logic Apps الهوية المدارة المعينة من قبل النظام والهوية المدارة المعينة من قبل المستخدم. تصف القائمة التالية بعض الاختلافات بين أنواع الهوية المدارة هذه:

يمكن لمورد تطبيق المنطق تمكين واستخدام هوية فريدة فقط يعينها النظام.
يمكن لمورد تطبيق المنطق مشاركة نفس الهوية المعينة من قبل المستخدم عبر مجموعة من موارد تطبيق المنطق الأخرى.

يوضح هذا الدليل كيفية إكمال المهام التالية:

تمكين وإعداد الهوية المدارة المعينة من قبل النظام لمورد تطبيق المنطق الخاص بك. يوفر هذا الدليل مثالا يوضح كيفية استخدام الهوية للمصادقة.
إنشاء هوية معينة من قبل المستخدم وإعدادها. يوضح هذا الدليل كيفية إنشاء هوية معينة من قبل المستخدم باستخدام مدخل Microsoft Azure وقالب Azure Resource Manager (قالب ARM) وكيفية استخدام الهوية للمصادقة. بالنسبة إلى Azure PowerShell وAzure CLI وAzure REST API، راجع الوثائق التالية:

الأداة	‏‏الوثائق
Azure PowerShell	إنشاء هوية يُعينها المستخدم
Azure CLI	إنشاء هوية يُعينها المستخدم
Azure REST API	إنشاء هوية يُعينها المستخدم

تطبيق منطق "الاستهلاك" مقابل تطبيق منطق "قياسي"

استنادًا إلى نوع مورد تطبيق المنطق الخاص بك، يمكنك تمكين الهوية المعينة من قبل النظام أو الهوية المعينة من قبل المستخدم أو كليهما في نفس الوقت:

تطبيق المنطق	البيئة	دعم الهوية المدارة
الاستهلاك‬	- تطبيقات Azure Logic Apps متعددة المستأجرين - بيئة خدمة التكامل (ISE)	- يمكن لتطبيق المنطق الخاص بك تمكين الهوية المعينة من قبل النظام أو الهوية المعينة من قبل المستخدم. - يمكنك استخدام الهوية المدارة على مستوى مورد التطبيق المنطقي ومستوى الاتصال. - إذا قمت بتمكين الهوية المعينة من قبل المستخدم، يمكن أن يكون لتطبيق المنطق الخاص بك هوية واحدة فقط يعينها المستخدم في كل مرة.
قياسي	- تطبيقات Azure Logic Apps أحادية المستأجر - App Service Environment v3 (ASEv3) - تمكين Azure Arc لـ Logic Apps	- يمكنك تمكين كل من الهوية المعينة من قبل النظام، والتي يتم تمكينها افتراضيا، والهوية المعينة من قبل المستخدم في نفس الوقت. - يمكنك استخدام الهوية المدارة على مستوى مورد التطبيق المنطقي ومستوى الاتصال. - إذا قمت بتمكين الهوية المعينة من قبل المستخدم، يمكن أن يكون لمورد تطبيق المنطق الخاص بك هويات متعددة يعينها المستخدم في نفس الوقت.

للحصول على معلومات حول حدود الهوية المدارة في Azure Logic Apps، راجع حدود الهويات المدارة لتطبيقات المنطق. لمزيد من المعلومات حول أنواع موارد التطبيق المنطقي القياسي والاستهلاك والبيئات، راجع الوثائق التالية:

حيث يمكنك استخدام هوية مدارة

في Azure Logic Apps، يمكن فقط لعمليات موصل مضمنة ومدارة محددة تدعم OAuth مع معرف Microsoft Entra استخدام هوية مدارة للمصادقة. توفر الجداول التالية عينة تحديد فقط. للحصول على قائمة أكثر اكتمالا، راجع أنواع المصادقة للمشغلات والإجراءات التي تدعم المصادقة وخدمات Azure التي تدعم مصادقة Microsoft Entra مع الهويات المدارة.

الاستهلاك
قياسي

بالنسبة لسير عمل تطبيق Consumption logic، يسرد الجدول التالي الموصلات التي تدعم مصادقة الهوية المدارة:

نوع الموصل	الموصلات المدعومة
مضمّن	- إدارة واجهة برمجة تطبيقات Azure - Azure App Services - Azure Functions - HTTP - HTTP + Webhook ملاحظة: يمكن لعمليات HTTP مصادقة الاتصالات بحسابات Azure Storage خلف جدران حماية Azure باستخدام الهوية المعينة من قبل النظام. ومع ذلك، فإنها لا تدعم الهوية المدارة المعينة من قبل المستخدم لمصادقة نفس الاتصالات.
مُدارة	- Azure App Service - Azure Automation - Azure Blob Storage - مثيل حاوية Azure - Azure Cosmos DB - Azure Data Explorer - Azure Data Factory - Azure Data Lake - Azure Event Grid - مراكز أحداث Azure - Azure IoT Central V2 - Azure IoT Central V3 - Azure Key Vault - Azure Log Analytics - قوائم انتظار Azure - Azure Resource Manager - ناقل خدمة Azure - Azure Sentinel - Azure Table Storage - Azure VM - HTTP مع معرف Microsoft Entra - SQL Server

نوع الموصل

الموصلات المدعومة

مضمّن

- إدارة واجهة برمجة تطبيقات Azure
- Azure App Services
- Azure Functions
- HTTP
- HTTP + Webhook

ملاحظة: يمكن لعمليات HTTP مصادقة الاتصالات بحسابات Azure Storage خلف جدران حماية Azure باستخدام الهوية المعينة من قبل النظام. ومع ذلك، فإنها لا تدعم الهوية المدارة المعينة من قبل المستخدم لمصادقة نفس الاتصالات.

مُدارة

- Azure App Service
- Azure Automation
- Azure Blob Storage
- مثيل حاوية Azure
- Azure Cosmos DB
- Azure Data Explorer
- Azure Data Factory
- Azure Data Lake
- Azure Event Grid
- مراكز أحداث Azure
- Azure IoT Central V2
- Azure IoT Central V3
- Azure Key Vault
- Azure Log Analytics
- قوائم انتظار Azure
- Azure Resource Manager
- ناقل خدمة Azure
- Azure Sentinel
- Azure Table Storage
- Azure VM
- HTTP مع معرف Microsoft Entra
- SQL Server

بالنسبة لسير عمل تطبيق المنطق القياسي، يسرد الجدول التالي الموصلات التي تدعم مصادقة الهوية المدارة:

نوع الموصل	الموصلات المدعومة
مضمّن	- Azure Automation - Azure Blob Storage - مراكز أحداث Azure - ناقل خدمة Azure - قوائم انتظار Azure - جداول Azure - HTTP - HTTP + Webhook - SQL Server ملاحظة: باستثناء موصلات SQL Server وHTTP، لا تدعم معظم الموصلات المضمنة والمستندة إلى موفر الخدمة حاليا تحديد الهويات المدارة المعينة من قبل المستخدم للمصادقة. بدلا من ذلك، يجب استخدام الهوية المعينة من قبل النظام. يمكن لعمليات HTTP مصادقة الاتصالات بحسابات Azure Storage خلف جدران حماية Azure باستخدام الهوية المعينة من قبل النظام.
مُدارة	- Azure App Service - Azure Automation - Azure Blob Storage - مثيل حاوية Azure - Azure Cosmos DB - Azure Data Explorer - Azure Data Factory - Azure Data Lake - Azure Event Grid - مراكز أحداث Azure - Azure IoT Central V2 - Azure IoT Central V3 - Azure Key Vault - Azure Log Analytics - قوائم انتظار Azure - Azure Resource Manager - ناقل خدمة Azure - Azure Sentinel - Azure Table Storage - Azure VM - HTTP مع معرف Microsoft Entra - SQL Server

نوع الموصل

الموصلات المدعومة

مضمّن

- Azure Automation
- Azure Blob Storage
- مراكز أحداث Azure
- ناقل خدمة Azure
- قوائم انتظار Azure
- جداول Azure
- HTTP
- HTTP + Webhook
- SQL Server

ملاحظة: باستثناء موصلات SQL Server وHTTP، لا تدعم معظم الموصلات المضمنة والمستندة إلى موفر الخدمة حاليا تحديد الهويات المدارة المعينة من قبل المستخدم للمصادقة. بدلا من ذلك، يجب استخدام الهوية المعينة من قبل النظام. يمكن لعمليات HTTP مصادقة الاتصالات بحسابات Azure Storage خلف جدران حماية Azure باستخدام الهوية المعينة من قبل النظام.

مُدارة

المتطلبات الأساسية

حساب واشتراك Azure. إذا لم يكن لديك اشتراك، فيجب التسجيل للحصول على حساب Azure مجاني. يجب أن تستخدم كل من الهوية المدارة ومورد Azure الهدف حيث تحتاج إلى الوصول نفس اشتراك Azure.
مورد Azure الهدف الذي تريد الوصول إليه. في هذا المورد، ستضيف الدور الضروري للهوية المدارة للوصول إلى هذا المورد نيابة عن تطبيق المنطق أو الاتصال. لإضافة دور إلى هوية مدارة، تحتاج إلى أذونات مسؤول Microsoft Entra التي يمكنها تعيين أدوار للهويات في مستأجر Microsoft Entra المقابل.
مورد التطبيق المنطقي وسير العمل حيث تريد استخدام المشغل أو الإجراءات التي تدعم الهويات المدارة.

تمكين الهوية المعينة من قبل النظام في مدخل Microsoft Azure

الاستهلاك
قياسي

في مدخل Microsoft Azure، افتح مورد التطبيق المنطقي.
في قائمة logic app، ضمن Settings، حدد Identity.

في صفحة الهوية، ضمن النظام المعين، حدد عند>الحفظ. عندما يطالبك Azure بالتأكيد، حدد نعم.

Screenshot shows Azure portal, Consumption logic app, Identity page, and System assigned tab with selected options, On and Save.

إشعار

إذا تلقيت خطأ بأنه يمكن أن يكون لديك هوية مدارة واحدة فقط، فإن مورد تطبيق المنطق الخاص بك مقترن بالفعل بالهوية المعينة من قبل المستخدم. قبل أن تتمكن من إضافة الهوية المعينة من قبل النظام، يجب أولا إزالة الهوية المعينة من قبل المستخدم من مورد تطبيق المنطق الخاص بك.

يمكن لمورد تطبيق المنطق الآن استخدام الهوية المعينة من قبل النظام. يتم تسجيل هذه الهوية مع معرف Microsoft Entra ويتم تمثيلها بواسطة معرف كائن.

Screenshot shows Consumption logic app, Identity page, and object ID for system-assigned identity.

الخاصية	القيمة	‏‏الوصف
معرف الكائن (الأساسي)	<معرف مورد الهوية>	معرف فريد عمومي (GUID) يمثل الهوية المعينة من قبل النظام لتطبيق المنطق الخاص بك في مستأجر Microsoft Entra.

الآن اتبع الخطوات التي تمنح هذه الهوية حق الوصول إلى المورد لاحقا في هذا الدليل.

في مورد تطبيق المنطق القياسي، يتم تمكين الهوية المعينة من قبل النظام تلقائيا. لتأكيد الهوية أو تمكينها، اتبع الخطوات التالية:

في مدخل Microsoft Azure، افتح مورد التطبيق المنطقي.
في قائمة logic app، ضمن Settings، حدد Identity.

في صفحة الهوية، ضمن النظام المعين، حدد عند>الحفظ. عندما يطالبك Azure بالتأكيد، حدد نعم.

Screenshot shows Azure portal, Standard logic app, Identity page, and System assigned tab with selected options for On and Save.

يمكن لمورد تطبيق المنطق الآن استخدام الهوية المعينة من قبل النظام، والمسجلة بمعرف Microsoft Entra ويتم تمثيلها بواسطة معرف كائن.

Screenshot shows Standard logic app, Identity page, and object ID for system-assigned identity.

الخاصية	القيمة	‏‏الوصف
معرف الكائن (الأساسي)	<معرف مورد الهوية>	معرف فريد عمومي (GUID) يمثل الهوية المعينة من قبل النظام لتطبيق المنطق الخاص بك في مستأجر Microsoft Entra.

الآن اتبع الخطوات التي تمنح هذه الهوية حق الوصول إلى المورد لاحقا في هذا الدليل.

تمكين الهوية المعينة من قبل النظام في قالب ARM

لأتمتة إنشاء موارد تطبيق المنطق ونشرها، يمكنك استخدام قالب ARM. لتمكين الهوية المعينة من قبل النظام لمورد تطبيق المنطق الخاص بك في القالب، أضف identity العنصر والخاصية type التابعة إلى تعريف مورد تطبيق المنطق في القالب، على سبيل المثال:

الاستهلاك
قياسي

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

{
   "apiVersion": "2021-01-15",
   "type": "Microsoft.Web/sites",
   "name": "[variables('sites_<logic-app-resource-name>_name')]",
   "location": "[resourceGroup().location]",
   "kind": "functionapp,workflowapp",
   "identity": {
      "type": "SystemAssigned"
   },
   "properties": {},
   <...>
}

عندما ينشئ Azure تعريف مورد تطبيق المنطق الخاص بك، يحصل الكائن identity على هذه الخصائص الأخرى:

"identity": {
   "type": "SystemAssigned",
   "principalId": "<principal-ID>",
   "tenantId": "<Azure-AD-tenant-ID>"
}

خاصية (JSON)	قيمة	‏‏الوصف
`principalId`	<principal-ID>	المعرف الفريد العمومي (GUID) للكائن الأساسي للخدمة للهوية المدارة التي تمثل تطبيق المنطق الخاص بك في مستأجر Microsoft Entra. يظهر هذا المعرف الفريد العمومي أحيانًا على أنه "عنصر كائن" أو `objectID`.
`tenantId`	<Azure-AD-tenant-ID>	المعرف الفريد العمومي (GUID) الذي يمثل مستأجر Microsoft Entra حيث أصبح تطبيق المنطق الآن عضوا. داخل مستأجر Microsoft Entra، يكون لمدير الخدمة نفس اسم مثيل تطبيق المنطق.

إنشاء هوية معينة من قبل المستخدم في مدخل Azure

قبل أن تتمكن من تمكين الهوية المعينة من قبل المستخدم على مورد تطبيق منطق الاستهلاك أو مورد تطبيق المنطق القياسي، يجب إنشاء هذه الهوية كمورد Azure منفصل.

في مربع البحث في مدخل Microsoft Azure، أدخل الهويات المدارة، وحدد الهويات المدارة.
في صفحة الهويات المدارة ، حدد إنشاء.

قم بتوفير معلومات حول هويتك المدارة، وحدد Review + Create، على سبيل المثال:

Screenshot shows page named Create User Assigned Managed Identity, with managed identity details.

الخاصية	المطلوب	قيمة	‏‏الوصف
الاشتراك	‏‏نعم‬	<"Azure-subscription-name">	اسم اشتراك Azure
مجموعة الموارد	‏‏نعم‬	<اسم مجموعة الموارد>	اسم مجموعة موارد Azure. إنشاء مجموعة جديدة، أو تحديد مجموعة موجودة. ينشئ هذا المثال مجموعة جديدة تسمى fabrikam-managed-identities-RG.
المنطقة	‏‏نعم‬	<تحديد منطقة Azure>	منطقة Azure حيث لتخزين معلومات حول المورد الخاص بك. يستخدم هذا المثال غرب الولايات المتحدة.
الاسم	‏‏نعم‬	<user-assigned-identity-name>	الاسم الذي يجب أن يعطي هويتك المعينة من قبل المستخدم. يستخدم هذا المثال Fabrikam-user-assigned-identity.

بعد أن يتحقق Azure من صحة المعلومات، يقوم Azure بإنشاء هويتك المدارة. الآن يمكنك إضافة الهوية المعينة من قبل المستخدم إلى مورد تطبيق المنطق الخاص بك.

إضافة هوية معينة من قبل المستخدم إلى تطبيق المنطق في مدخل Microsoft Azure

الاستهلاك
قياسي

في مدخل Microsoft Azure، افتح مورد التطبيق المنطقي.
في قائمة logic app، ضمن Settings، حدد Identity.
في صفحة Identity، حدد User assigned>Add.
في جزء إضافة هوية مدارة معينة من قبل المستخدم، اتبع الخطوات التالية:
1. من قائمة الاشتراك، حدد اشتراك Azure الخاص بك.
2. من القائمة التي تحتوي على جميع الهويات المدارة في اشتراكك، حدد الهوية المعينة من قبل المستخدم التي تريدها. لتصفية القائمة، في مربع البحث الهويات المدارة المعينة من قبل المستخدم، أدخل اسم الهوية أو مجموعة الموارد.
3. عندما تنتهي، حدد إضافة.
  
  إشعار
  
  إذا تلقيت خطأ بأنه يمكن أن يكون لديك هوية مدارة واحدة فقط، فإن تطبيق المنطق الخاص بك مقترن بالفعل بالهوية المعينة من قبل النظام. قبل أن تتمكن من إضافة الهوية المعينة من قبل المستخدم، يجب عليك أولًا تعطيل الهوية المعينة من قبل النظام.
يرتبط تطبيق المنطق الآن بالهوية المدارة المعينة من قبل المستخدم.
الآن اتبع الخطوات التي تمنح هذه الهوية حق الوصول إلى المورد لاحقا في هذا الدليل.

إنشاء هوية معينة من قبل المستخدم في قالب ARM

لأتمتة إنشاء موارد تطبيق المنطق ونشرها، يمكنك استخدام قالب ARM. تدعم هذه القوالب الهويات المعينة من قبل المستخدم للمصادقة.

في قسم القالب resources الخاص بك، يتطلب تعريف مورد تطبيق المنطق هذه العناصر:

عنصر identity⁧⁩ مع تعيين الخاصية type إلى UserAssigned⁧⁩
كائن تابع userAssignedIdentities يحدد المورد والاسم المعينين من قبل المستخدم

الاستهلاك
قياسي

يوضح هذا المثال مورد تطبيق منطق الاستهلاك وتعريف سير العمل لطلب HTTP PUT مع كائن غير معلمات identity . تتضمن الاستجابة لطلب PUT عملية GET اللاحقة أيضا هذا identity الكائن:

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {<template-parameters>},
   "resources": [
      {
         "apiVersion": "2016-06-01",
         "type": "Microsoft.logic/workflows",
         "name": "[variables('logicappName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-assigned-identity-name>": {}
            }
         },
         "properties": {
            "definition": {<logic-app-workflow-definition>}
         },
         "parameters": {},
         "dependsOn": []
      },
   ],
   "outputs": {}
}

إذا كان القالب الخاص بك يتضمن أيضًا تعريف مورد الهوية المدارة، يمكنك تحديد معلمات العنصر identity. يوضح المثال التالي كيف يشير الكائن التابع userAssignedIdentities إلى userAssignedIdentityName متغير تقوم بتعريفه في قسم القالب variables الخاص بك. يشير هذا المتغير إلى معرف المورد للهوية المعينة من قبل المستخدم.

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

يمكن لمورد تطبيق المنطق القياسي تمكين واستخدام كل من الهوية المعينة من قبل النظام والهويات المتعددة المعينة من قبل المستخدم. يستند تعريف مورد تطبيق المنطق القياسي إلى تعريف مورد تطبيق دالة Azure Functions.

يوضح هذا المثال مورد تطبيق المنطق القياسي وتعريف سير العمل الذي يتضمن كائنا غير معلمات identity :

{
   "$schema": "https://schema.management.azure.com/schemas/2019-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {<template-parameters>},
   "resources": [
      {
         "apiVersion": "2021-02-01",
         "type": "Microsoft.Web/sites/functions",
         "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": {
            "name": "[variables('appName')]",
            "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
            "hostingEnvironment": "",
            "clientAffinityEnabled": false,
            "alwaysOn": true
         },
         "parameters": {},
         "dependsOn": []
      }
   ],
   "outputs": {}
}

{
   "$schema": "https://schema.management.azure.com/schemas/2019-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {<template-parameters>},
   "resources": [
      {
         "apiVersion": "2021-02-01",
         "type": "Microsoft.Web/sites/functions",
         "name": "[variables('logicappName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "[resourceId(Microsoft.ManagedIdentity/userAssignedIdentities', variables('userAssignedIdentityName'))]": {}
            }
         },
         "properties": {
            "name": "[variables('appName')]",
            "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
            "hostingEnvironment": "",
            "clientAffinityEnabled": false,
            "alwaysOn": true
         },
         "parameters": {},
         "dependsOn": [
            "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
            "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]"
         ]
      },
      {
         "apiVersion": "2018-11-30",
         "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
         "name": "[parameters('Template_UserAssignedIdentityName')]",
         "location": "[resourceGroup().location]",
         "properties": {}
      },
   ],
   "outputs": {}
}

عندما ينشئ القالب مورد تطبيق منطقي، identity يتضمن الكائن الخصائص التالية:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<resource-ID>": {
            "principalId": "<principal-ID>",
            "clientId": "<client-ID>"
        }
    }
}

principalId قيمة الخاصية هي معرف فريد للهوية المستخدمة لإدارة Microsoft Entra. قيمة الخاصية clientId هي معرف فريد للهوية الجديدة لتطبيق المنطق والتي يتم استخدامها لتحديد الهوية التي يجب استخدامها أثناء مكالمات وقت التشغيل. لمزيد من المعلومات حول قوالب Azure Resource Manager والهويات المدارة ل Azure Functions، راجع قالب ARM - Azure Functions وإضافة هوية معينة من قبل المستخدم باستخدام قالب ARM ل Azure Functions.

منح حق الوصول إلى الموارد للهوية

قبل أن تتمكن من استخدام هويتك المُدارة التابعة لتطبيق منطقك للمصادقة، عليك إعداد الوصول إلى تلك الهوية على مورد Azure حيث تخطط لاستخدام الهوية. تختلف طريقة إعداد الوصول استنادًا إلى المورد الذي تريد للهوية الوصول إليه.

إشعار

عندما يكون للهوية المدارة حق الوصول إلى مورد Azure في نفس الاشتراك، يمكن للهوية الوصول إلى هذا المورد فقط. ومع ذلك، في بعض المشغلات والإجراءات التي تدعم الهويات المدارة، يجب عليك أولًا تحديد مجموعة موارد Azure التي تحتوي على المورد الهدف. إذا لم يكن للهوية حق الوصول على مستوى مجموعة الموارد، فلن يتم سرد أي موارد في تلك المجموعة، على الرغم من وجود حق الوصول إلى المورد الهدف.

للتعامل مع هذا السلوك، يجب أيضًا منح الهوية حق الوصول إلى مجموعة الموارد، وليس فقط المورد. وبالمثل، إذا كان عليك تحديد اشتراكك قبل أن تتمكن من تحديد المورد الهدف، يجب منح الهوية حق الوصول إلى الاشتراك.

في بعض الحالات، قد تحتاج إلى الهوية للوصول إلى المورد المقترن. على سبيل المثال، افترض أن لديك هوية مدارة لتطبيق منطقي يحتاج إلى الوصول لتحديث إعدادات التطبيق لنفس التطبيق المنطقي من سير العمل. يجب منح هذه الهوية حق الوصول إلى تطبيق المنطق المقترن.

على سبيل المثال، للوصول إلى حساب تخزين Azure Blob باستخدام هويتك المدارة، يجب عليك إعداد الوصول باستخدام التحكم في الوصول المستند إلى دور Azure (Azure RBAC) وتعيين الدور المناسب لتلك الهوية إلى حساب التخزين. تصف الخطوات الواردة في هذا القسم كيفية إكمال هذه المهمة باستخدام مدخل Microsoft Azure وقالب Azure Resource Manager (قالب ARM). بالنسبة إلى Azure PowerShell وAzure CLI وAzure REST API، راجع الوثائق التالية:

الأداة	‏‏الوثائق
Azure PowerShell	إضافة تعيين دور
Azure CLI	إضافة تعيين دور
Azure REST API	إضافة تعيين دور

ومع ذلك، للوصول إلى مخزن مفاتيح Azure باستخدام هويتك المدارة، يجب عليك إنشاء نهج وصول لتلك الهوية على مخزن المفاتيح الخاص بك وتعيين الأذونات المناسبة لتلك الهوية على مخزن المفاتيح هذا. تصف الخطوات اللاحقة في هذا القسم كيفية إكمال هذه المهمة باستخدام مدخل Microsoft Azure. للحصول على قوالب Resource Manager وPowerShell وAzure CLI، راجع الوثائق التالية:

الأداة	‏‏الوثائق
قالب Azure Resource Manager (قالب ARM)	تعريف مورد نهج الوصول Key Vault
Azure PowerShell	تعيين نهج وصول لـ Key Vault
Azure CLI	تعيين نهج وصول لـ Key Vault

تعيين الوصول المستند إلى دور الهوية المدارة في مدخل Microsoft Azure

لاستخدام هوية مدارة للمصادقة، تتطلب بعض موارد Azure، مثل حسابات تخزين Azure، تعيين هذه الهوية لدور لديه الأذونات المناسبة على المورد الهدف. تتطلب موارد Azure الأخرى، مثل خزائن مفاتيح Azure، إنشاء نهج وصول لديه الأذونات المناسبة على المورد الهدف لتلك الهوية.

في مدخل Microsoft Azure، افتح المورد الذي تريد استخدام الهوية فيه.
في قائمة الموارد، حدد Access control (IAM)>Add>Add role assignment.

إشعار

إذا تم تعطيل الخيار إضافة تعيين دور، فليس لديك أذونات لتعيين الأدوار. لمزيد من المعلومات، راجع الأدوار المضمنة في Microsoft Entra.
الآن، قم بتعيين الدور الضروري لهويتك المدارة. في علامة التبويب دور، قم بتعيين دور يمنح هويتك الوصول المطلوب إلى المورد الحالي.

على سبيل المثال، قم بتعيين الدور المسمى Storage Blob Data Contributor، والذي يتضمن الوصول للكتابة للكائنات الثنائية كبيرة الحجم في حاوية تخزين Azure. لمزيد من المعلومات حول أدوار حاوية تخزين معينة، راجع الأدوار التي يمكنها الوصول إلى الكائنات الثنائية كبيرة الحجم في حاوية تخزين Azure.
بعد ذلك، اختر الهوية المدارة حيث تريد تعيين الدور. ضمن تعيين الوصول إلى، حدد الهوية> المدارةإضافة أعضاء.

استنادًا إلى نوع الهوية المدارة، حدد القيم التالية أو قم بتوفيرها:

نوع	مثيل خدمة Azure	الوصف	العضو
النظام المعين	Logic App	<"Azure-subscription-name">	<your-logic-app-name>
المستخدم المعين	غير قابل للتطبيق	<"Azure-subscription-name">	<your-user-assigned-identity-name>

لمزيد من المعلومات حول تعيين الأدوار، راجع تعيين الأدوار باستخدام مدخل Microsoft Azure.

بعد الانتهاء، يمكنك استخدام الهوية لمصادقة الوصول للمشغلات والإجراءات التي تدعم الهويات المدارة.

لمزيد من المعلومات العامة حول هذه المهمة، راجع تعيين وصول هوية مدارة إلى مورد آخر باستخدام Azure RBAC.

إنشاء نهج الوصول في مدخل Microsoft Azure

لاستخدام هوية مدارة للمصادقة، تتطلب بعض موارد Azure، مثل خزائن مفاتيح Azure، إنشاء نهج وصول لديه الأذونات المناسبة على المورد الهدف لتلك الهوية. تتطلب موارد Azure الأخرى، مثل حسابات تخزين Azure، تعيين هذه الهوية لدور لديه الأذونات المناسبة على المورد الهدف.

في مدخل Microsoft Azure، افتح المورد الذي تريد استخدام الهوية فيه. يستخدم هذا المثال مخزن مفاتيح Azure كمورد مستهدف.
في قائمة المورد، حدد Access policies>Create، الذي يفتح جزء Create an access policy.

إشعار

إذا لم يكن لدى المورد خيار نهج الوصول، فحاول تعيين دور بدلًا من ذلك.
في علامة التبويب أذونات، حدد الأذونات المطلوبة التي تحتاج إليها الهوية للوصول إلى المورد الهدف.

على سبيل المثال، لاستخدام الهوية مع عملية List secrets الخاصة بموصل Azure Key Vault المدارة، تحتاج الهوية إلى أذونات List. لذلك، في عمود Secret permissions، حدد List.
عندما تصبح مستعداً، حدد "Next". في علامة التبويب Principal، ابحث عن الهوية المدارة وحددها، وهي هوية معينة من قبل المستخدم في هذا المثال.
تخطي خطوة التطبيق الاختيارية، وحدد التالي، وإنهاء إنشاء نهج الوصول.

يناقش القسم التالي استخدام هوية مدارة لمصادقة الوصول لمشغل أو إجراء. يستمر المثال مع الخطوات من قسم سابق حيث قمت بإعداد الوصول لهوية مدارة باستخدام RBAC ولا تستخدم Azure Key Vault كمثال. ومع ذلك، فإن الخطوات العامة لاستخدام هوية مدارة للمصادقة هي نفسها.

مصادقة الوصول باستخدام الهوية المدارة

بعد تمكين الهوية المدارة لمورد تطبيق المنطق الخاص بك ومنح هذه الهوية حق الوصول إلى المورد أو الكيان الهدف، يمكنك استخدام هذه الهوية في المشغلات والإجراءات التي تدعم الهويات المدارة.

هام

إذا كان لديك دالة Azure حيث تريد استخدام الهوية المعينة من قبل النظام، فبادر أولًا بتمكين المصادقة لوظائف Azure.

توضح هذه الخطوات كيفية استخدام الهوية المدارة مع مشغل أو إجراء من خلال مدخل Microsoft Azure. لتحديد الهوية المدارة في تعريف JSON الأساسي للمشغل أو الإجراء، راجع مصادقة الهوية المدارة.

الاستهلاك
قياسي

في مدخل Microsoft Azure، افتح مورد التطبيق المنطقي.
إذا لم تكن قد فعلت ذلك بعد، فأضف المشغل أو الإجراء الذي يدعم الهويات المدارة.

إشعار

لا تدعم جميع عمليات الموصل السماح لك بإضافة نوع مصادقة. لمزيد من المعلومات، راجع أنواع المصادقة للمشغلات والإجراءات التي تدعم المصادقة.
في المشغل أو الإجراء الذي أضفته، اتبع الخطوات التالية:
- عمليات الموصل المضمنة التي تدعم مصادقة الهوية المدارة
  1. من قائمة إضافة معلمات جديدة، أضف الخاصية Authentication إذا لم تظهر الخاصية بالفعل.
  2. من قائمة نوع المصادقة، حدد الهوية المدارة.
  لمزيد من المعلومات، راجع مثال: مصادقة المشغل المضمن أو الإجراء بهوية مدارة.
- عمليات الموصل المدارة التي تدعم مصادقة الهوية المدارة
  1. في صفحة تحديد المستأجر، حدد الاتصال بالهوية المدارة، على سبيل المثال:
  2. في الصفحة التالية، بالنسبة إلى اسم الاتصال، قم بتوفير اسم لاستخدامه للاتصال.
  3. بالنسبة لنوع المصادقة، اختر أحد الخيارات التالية استنادًا إلى الموصل المدار:
    - مصادقة أحادية: تدعم هذه الموصلات نوع مصادقة واحدا فقط. من قائمة الهوية المدارة، حدد الهوية المدارة الممكنة حاليا، إذا لم تكن محددة بالفعل، ثم حدد إنشاء، على سبيل المثال:
    - المصادقة المتعددة: تعرض هذه الموصلات أنواع مصادقة متعددة، ولكن لا يزال بإمكانك تحديد نوع واحد فقط. من قائمة نوع المصادقة، حدد Logic Apps Managed Identity>Create، على سبيل المثال:
    لمزيد من المعلومات، راجع مثال: مصادقة مشغل الموصل المدار أو إجراء باستخدام هوية مدارة.

مثال: مصادقة المشغل أو الإجراء المضمن بهوية مدارة

يمكن لمشغل أو إجراء HTTP المضمن استخدام الهوية المعينة من قبل النظام التي تقوم بتمكينها على مورد تطبيق المنطق الخاص بك. بشكل عام، يستخدم مشغل HTTP أو الإجراء الخصائص التالية لتحديد المورد أو الكيان الذي تريد الوصول إليه:

الخاصية	المطلوب	‏‏الوصف
الطريقة	‏‏نعم‬	أسلوب HTTP الذي تستخدمه العملية التي تريد تشغيلها
Uri	‏‏نعم‬	عنوان URL لنقطة النهاية للوصول إلى مورد أو كيان Azure الهدف. يتضمن بناء جملة URI عادة معرف المورد لمورد أو خدمة Azure.
رؤوس	لا	أي قيم رأس تحتاج إليها أو تريد تضمينها في الطلب الصادر، مثل نوع المحتوى
الاستعلامات	لا	أي معلمات استعلام تحتاج إليها أو تريد تضمينها في الطلب. على سبيل المثال، معلمات الاستعلام لعملية معينة أو لإصدار واجهة برمجة التطبيقات للعملية التي تريد تشغيلها.
المصادقة	‏‏نعم‬	نوع المصادقة الذي يجب استخدامه لمصادقة الوصول إلى المورد أو الكيان الهدف

كمثال محدد، افترض أنك تريد تشغيل عملية Snapshot Blob على كائن ثنائي كبير الحجم في حساب Azure Storage حيث قمت مسبقًا بإعداد الوصول لهويتك. ومع ذلك، لا يقدم موصل Azure Blob Storage هذه العملية حاليًا. بدلًا من ذلك، يمكنك تشغيل هذه العملية باستخدام إجراء HTTP أو عملية واجهة برمجة تطبيقات REST لخدمة Blob أخرى.

هام

للوصول إلى حسابات تخزين Azure خلف جدران الحماية باستخدام طلبات HTTP والهويات المدارة، تأكد أيضا من إعداد حساب التخزين الخاص بك باستثناء الذي يسمح بالوصول بواسطة خدمات Microsoft الموثوق بها.

لتشغيل عملية Snapshot Blob، يحدد إجراء HTTP هذه الخصائص:

الخاصية	المطلوب	قيمة المثال	‏‏الوصف
الطريقة	‏‏نعم‬	`PUT`	أسلوب HTTP الذي تستخدمه عملية Snapshot Blob
Uri	‏‏نعم‬	`https://<storage-account-name>/<folder-name>/{name}`	معرف المورد لملف Azure Blob Storage في بيئة Azure Global (العامة)، والذي يستخدم بناء الجملة هذا
رؤوس	بالنسبة إلى تخزين Azure	`x-ms-blob-type` = `BlockBlob` `x-ms-version` = `2019-02-02` `x-ms-date` = `@{formatDateTime(utcNow(),'r')}`	قيم العنوان `x-ms-blob-type` و`x-ms-version` و`x-ms-date` مطلوبة لعمليات تخزين Azure. هام: في مشغل HTTP الصادر وطلبات الإجراء لـAzure Storage، يتطلب العنوان الخاصية `x-ms-version` وإصدار واجهة برمجة التطبيقات للعملية التي تريد تشغيلها. يجب أن يكون `x-ms-date` التاريخ الحالي. وإلا، يفشل سير العمل الخاص بك مع وجود خطأ `403 FORBIDDEN`. للحصول على التاريخ الحالي بالتنسيق المطلوب، يمكنك استخدام التعبير في قيمة المثال. لمزيد من المعلومات، راجع الوثائق التالية: - عناوين الطلب - لقطة كائن ثنائي كبير الحجم - إصدار لخدمات تخزين Azure
الاستعلامات	فقط لعملية Snapshot Blob	`comp` = `snapshot`	اسم معلمة الاستعلام وقيمتها للعملية.

الاستهلاك
قياسي

يوضح المثال التالي نموذج إجراء HTTP مع كافة قيم الخصائص الموضحة مسبقًا لاستخدامها في عملية Snapshot Blob:

Screenshot shows Azure portal, Consumption workflow, and HTTP action set up to access resources.

بعد إضافة إجراء HTTP، أضف خاصية Authentication إلى إجراء HTTP. من قائمة Add new parameter، حدد Authentication.

إشعار

لا تدعم جميع المشغلات والإجراءات السماح لك بإضافة نوع مصادقة. لمزيد من المعلومات، راجع أنواع المصادقة للمشغلات والإجراءات التي تدعم المصادقة.
من قائمة نوع المصادقة، حدد الهوية المدارة.
من قائمة الهوية المدارة، حدد من الخيارات المتوفرة استنادًا إلى السيناريو الخاص بك.
- إذا قمت بإعداد الهوية المعينة من قبل النظام، فحدد الهوية المدارة المعينة من قبل النظام إذا لم تكن محددة بالفعل.
- إذا قمت بإعداد هوية معينة من قبل المستخدم، فحدد هذه الهوية إذا لم تكن محددة بالفعل.
يستمر هذا المثال مع الهوية المدارة المعينة من قبل النظام.
في بعض المشغلات والإجراءات، تظهر خاصية Audience أيضًا لتعيين معرف المورد الهدف. تعيين الخاصية Audience إلى معرف المورد للمورد أو الخدمة الهدف. وإلا، بشكل افتراضي، تستخدم خاصية Audience معرف المورد https://management.azure.com/، وهو معرف المورد لـAzure Resource Manager.

على سبيل المثال، إذا كنت تريد مصادقة الوصول إلى مورد Key Vault في سحابة Azure العمومية، يجب تعيين الخاصية Audience إلى معرف المورد التالي بالضبط: https://vault.azure.net. لا يحتوي معرف المورد المحدد هذا على أي شرطة مائلة لاحقة. في الواقع، قد يؤدي تضمين شرطة مائلة زائدة إما إلى حدوث خطأ 400 Bad Request أو خطأ 401 Unauthorized.

هام

تأكد من تطابق معرف المورد الهدف تماما مع القيمة التي يتوقعها معرف Microsoft Entra، بما في ذلك أي شرطة مائلة لاحقة مطلوبة. على سبيل المثال، يتطلب معرف المورد لكافة حسابات تخزين Azure Blob شرطة مائلة زائدة. يتطلب مُعرف المورد لجميع حسابات Azure Blob Storage شرطة مائلة زائدة. تحقق من معرفات الموارد لخدمات Azure التي تدعم معرف Microsoft Entra.

يعين هذا المثال الخاصية Audience إلى https://storage.azure.com/ بحيث تكون رموز الوصول المميزة المستخدمة للمصادقة صالحة لجميع حسابات التخزين. ومع ذلك، يُمكنك أيضًا تحديد URL خدمة الجذر، https://<your-storage-account>.blob.core.windows.net، لحساب تخزين معين.

لمزيد من المعلومات حول تخويل الوصول باستخدام معرف Microsoft Entra لتخزين Azure، راجع الوثائق التالية:
- تخويل الوصول إلى الكائنات الثنائية كبيرة الحجم وقوائم الانتظار في Azure باستخدام معرف Microsoft Entra
- تخويل الوصول إلى Azure Storage باستخدام معرف Microsoft Entra
تابع إنشاء سير العمل بالطريقة التي تريدها.

يوضح المثال التالي نموذج إجراء HTTP مع كافة قيم الخصائص الموضحة مسبقًا لاستخدامها في عملية Snapshot Blob:

Screenshot shows Azure portal, Standard workflow, and HTTP action set up to access resources.

بعد إضافة إجراء HTTP، أضف خاصية Authentication إلى إجراء HTTP. من قائمة Add new parameter، حدد Authentication.

إشعار

لا تدعم جميع المشغلات والإجراءات السماح لك بإضافة نوع مصادقة. لمزيد من المعلومات، راجع أنواع المصادقة للمشغلات والإجراءات التي تدعم المصادقة.
من قائمة نوع المصادقة، حدد الهوية المدارة.
من قائمة الهوية المدارة، حدد الهوية المدارة المعينة من قبل النظام إذا لم تكن محددة بالفعل.
في بعض المشغلات والإجراءات، تظهر خاصية Audience أيضًا لتعيين معرف المورد الهدف. تعيين الخاصية Audience إلى معرف المورد للمورد أو الخدمة الهدف. وإلا، بشكل افتراضي، تستخدم خاصية Audience معرف المورد https://management.azure.com/، وهو معرف المورد لـAzure Resource Manager.

على سبيل المثال، إذا كنت تريد مصادقة الوصول إلى مورد Key Vault في سحابة Azure العمومية، يجب تعيين الخاصية Audience إلى معرف المورد التالي بالضبط: https://vault.azure.net. لا يحتوي معرف المورد المحدد هذا على أي شرطة مائلة لاحقة. في الواقع، قد يؤدي تضمين شرطة مائلة زائدة إما إلى حدوث خطأ 400 Bad Request أو خطأ 401 Unauthorized.

هام

تأكد من تطابق معرف المورد الهدف تماما مع القيمة التي يتوقعها معرف Microsoft Entra، بما في ذلك أي شرطة مائلة لاحقة مطلوبة. على سبيل المثال، يتطلب معرف المورد لكافة حسابات تخزين Azure Blob شرطة مائلة زائدة. يتطلب مُعرف المورد لجميع حسابات Azure Blob Storage شرطة مائلة زائدة. تحقق من معرفات الموارد لخدمات Azure التي تدعم معرف Microsoft Entra.

يعين هذا المثال الخاصية Audience إلى https://storage.azure.com/ بحيث تكون رموز الوصول المميزة المستخدمة للمصادقة صالحة لجميع حسابات التخزين. ومع ذلك، يُمكنك أيضًا تحديد URL خدمة الجذر، https://<your-storage-account>.blob.core.windows.net، لحساب تخزين معين.

لمزيد من المعلومات حول تخويل الوصول باستخدام معرف Microsoft Entra لتخزين Azure، راجع الوثائق التالية:
- تخويل الوصول إلى الكائنات الثنائية كبيرة الحجم وقوائم الانتظار في Azure باستخدام معرف Microsoft Entra
- تخويل الوصول إلى Azure Storage باستخدام معرف Microsoft Entra
تابع إنشاء سير العمل بالطريقة التي تريدها.

مثال: مصادقة مشغل الموصل المدار أو الإجراء باستخدام هوية مدارة

يحتوي موصل Azure Resource Manager المدار على إجراء يسمى Read a resource، والذي يمكنه استخدام الهوية المدارة التي تقوم بتمكينها على مورد تطبيق المنطق الخاص بك. يوضح هذا المثال كيفية استخدام الهوية المدارة المعينة من قبل النظام.

الاستهلاك
قياسي

بعد إضافة الإجراء إلى سير العمل وتحديد مستأجر Microsoft Entra، حدد الاتصال بهوية مدارة.
في صفحة اسم الاتصال، قم بتوفير اسم للاتصال، وحدد الهوية المدارة التي تريد استخدامها.

إجراء Azure Resource Manager هو إجراء مصادقة واحدة، لذلك يعرض مربع معلومات الاتصال قائمة هوية مدارة تحدد تلقائيا الهوية المدارة التي تم تمكينها حاليا على مورد تطبيق المنطق. إذا قمت بتمكين هوية مدارة معينة من قبل النظام، تحدد قائمة الهوية المدارةالهوية المدارة المعينة من قبل النظام. إذا قمت بتمكين هوية مدارة معينة من قبل المستخدم بدلًا من ذلك، تحدد القائمة هذه الهوية بدلًا من ذلك.

إذا كنت تستخدم مشغل مصادقة متعددة أو إجراء، مثل Azure Blob Storage، يعرض مربع معلومات الاتصال قائمة نوع المصادقة التي تتضمن خيار Logic Apps Managed Identity من بين أنواع المصادقة الأخرى.

في هذا المثال، الهوية المدارة المعينة من قبل النظام هي التحديد الوحيد المتاح.

إشعار

إذا لم يتم تمكين الهوية المدارة عند محاولة إنشاء الاتصال أو تغيير الاتصال أو تمت إزالته في أثناء استمرار وجود اتصال مدار ممكن للهوية، يظهر خطأ أنه يجب تمكين الهوية ومنح حق الوصول إلى المورد الهدف.
عندما تكون مستعداً، حدد Create.
بعد أن يقوم المصمم بإنشاء الاتصال بنجاح، يمكن للمصمم إحضار أي قيم ديناميكية أو محتوى أو مخطط باستخدام مصادقة الهوية المدارة.
تابع إنشاء سير العمل بالطريقة التي تريدها.

تعريف مورد تطبيق المنطق والاتصالات التي تستخدم هوية مدارة

الاتصال الذي يمكن الهوية المدارة ويستخدمها هو نوع اتصال خاص يعمل فقط مع هوية مدارة. في وقت التشغيل، يستخدم الاتصال الهوية المدارة التي تم تمكينها على مورد تطبيق المنطق. في وقت التشغيل، تتحقق خدمة Azure Logic Apps مما إذا كان يتم إعداد أي مشغل موصل مدار وإجراءات في سير عمل تطبيق المنطق لاستخدام الهوية المدارة وإعداد جميع الأذونات المطلوبة لاستخدام الهوية المدارة للوصول إلى الموارد المستهدفة المحددة بواسطة المشغل والإجراءات. إذا نجحت، يسترد Azure Logic Apps الرمز المميز ل Microsoft Entra المرتبط بالهوية المدارة ويستخدم هذه الهوية لمصادقة الوصول إلى المورد الهدف وتنفيذ العملية المكونة في المشغل والإجراءات.

الاستهلاك
قياسي

في مورد تطبيق منطق الاستهلاك، يتم حفظ تكوين الاتصال في كائن تعريف parameters مورد التطبيق المنطقي، والذي يحتوي على $connections العنصر الذي يتضمن المؤشرات إلى معرف مورد الاتصال مع معرف مورد الهوية، إذا تم تمكين الهوية المعينة من قبل المستخدم.

يوضح هذا المثال كيف يبدو التكوين عندما يمكن تطبيق المنطق الهوية المدارة المعينة من قبل النظام:

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

يوضح هذا المثال كيف يبدو التكوين عندما يمكن تطبيق المنطق الهوية المدارة المعينة من قبل المستخدم:

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

في مورد تطبيق المنطق القياسي، يتم حفظ تكوين الاتصال في مورد تطبيق المنطق أو ملف المشروع connections.json ، والذي يحتوي على كائن managedApiConnections JSON يتضمن معلومات تكوين الاتصال لكل موصل مدار مستخدم في سير العمل. على سبيل المثال، تتضمن معلومات الاتصال هذه المؤشرات إلى معرف مورد الاتصال جنبًا إلى جنب مع خصائص الهوية المدارة، مثل معرف المورد، إذا تم تمكين الهوية المعينة من قبل المستخدم.

يوضح هذا المثال كيف يبدو التكوين عندما يمكن تطبيق المنطق الهوية المدارة المعينة من قبل النظام:

{
    "managedApiConnections": {
        "<connector-name>": {
            "api": {
                "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/<connector-name>"
            },
            "authentication": { // Authentication for the internal token store
                "type": "ManagedServiceIdentity"
            },
            "connection": {
                "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-name>"
            },
            "connectionProperties": {
                "authentication": { // Authentication for the target resource
                    "audience": "<resource-URL>",
                    "type": "ManagedServiceIdentity"
                }
            },
            "connectionRuntimeUrl": "<connection-runtime-URL>"
        }
    }
}

يوضح هذا المثال كيف يبدو التكوين عندما يمكن تطبيق المنطق الهوية المدارة المعينة من قبل المستخدم:

{
    "managedApiConnections": {
        "<connector-name>": {
            "api": {
                "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/<connector-name>"
            },
            "authentication": { // Authentication for the internal token store
                "type": "ManagedServiceIdentity"
            },
            "connection": {
                "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-name>"
            },
            "connectionProperties": {
                "authentication": { // Authentication for the target resource
                    "audience": "<resource-URL>",     
                    "type": "ManagedServiceIdentity",
                    "identity": "<user-assigned-identity>" // Optional
                }
            },
            "connectionRuntimeUrl": "<connection-runtime-URL>"
        }
    }
}

قالب ARM لاتصالات واجهة برمجة التطبيقات والهويات المدارة

إذا كنت تستخدم قالب ARM لأتمتة النشر، وكان سير العمل الخاص بك يتضمن اتصال API، والذي يتم إنشاؤه بواسطة موصل مدار مثل Office 365 Outlook وAzure Key Vault وما إلى ذلك الذي يستخدم هوية مدارة، لديك خطوة إضافية لاتخاذها.

في قالب ARM، يختلف تعريف مورد الموصل الأساسي استنادًا إلى ما إذا كان لديك تطبيق منطق الاستهلاك أو قياسي وما إذا كان الموصل يعرض خيارات المصادقة المفردة أو المصادقة المتعددة.

الاستهلاك
قياسي

تنطبق الأمثلة التالية على موارد تطبيق منطق الاستهلاك وتظهر كيف يختلف تعريف مورد الموصل الأساسي بين موصل مصادقة واحدة، مثل Azure Automation، وموصل متعدد المصادقة، مثل Azure Blob Storage.

مصادقة أحادية

يوضح هذا المثال تعريف مورد الاتصال الأساسي لإجراء Azure Automation في تطبيق منطق الاستهلاك الذي يستخدم هوية مدارة حيث يتضمن التعريف السمات:

يتم تعيين الخاصية kind إلى V1 لتطبيق منطق الاستهلاك.
تم تعيين الخاصية parameterValueType على Alternative.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_azureautomation_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues": {},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureautomation')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_azureautomation_name')]",
        "parameterValueSet": {},
        "parameterValueType": "Alternative"
    }
},

مصادقة متعددة

يوضح هذا المثال تعريف مورد الاتصال الأساسي لإجراء Azure Blob Storage في تطبيق منطق الاستهلاك الذي يستخدم هوية مدارة حيث يتضمن التعريف السمات التالية:

يتم تعيين الخاصية kind إلى V1 لتطبيق منطق الاستهلاك.
يتضمن الكائن parameterValueSet خاصية name تم تعيينها إلى managedIdentityAuth وخاصية values تم تعيينها إلى كائن فارغ.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_azureblob_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues":{},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureblob')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_azureblob_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        },
        "parameterValueType": "Alternative"
    }
}

تنطبق الأمثلة التالية على تطبيقات المنطق القياسية وتوضح كيف يختلف تعريف مورد الموصل الأساسي بين موصل مصادقة واحدة، مثل Azure Automation، وموصل متعددة المصادقة، مثل Azure Blob Storage.

مصادقة أحادية

يوضح هذا المثال تعريف مورد الاتصال الأساسي لإجراء Azure Automation في تطبيق منطق قياسي يستخدم هوية مدارة حيث يتضمن التعريف السمات التالية:

تم تعيين الخاصية kind إلى V2 لتطبيق منطق قياسي.
تم تعيين الخاصية parameterValueType على Alternative.

{
    "type": "Microsoft.Web/connections",
    "name": "[variables('connections_azureautomation_name')]",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "location": "[parameters('location')]",
    "kind": "V2",
    "properties": {
        "alternativeParameterValues": {},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureautomation')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_azureautomation_name')]",
        "parameterValueSet": {},
        "parameterValueType": "Alternative"
    }
},

مصادقة متعددة

يوضح هذا المثال تعريف مورد الاتصال الأساسي لإجراء Azure Blob Storage في تطبيق منطق قياسي يستخدم هوية مدارة حيث يتضمن التعريف السمات التالية:

تم تعيين الخاصية kind إلى V2 لتطبيق منطق قياسي.
يتضمن الكائن parameterValueSet خاصية name تم تعيينها إلى managedIdentityAuth وخاصية values تم تعيينها إلى كائن فارغ.

{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_azureblob_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues":{},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureblob')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_azureblob_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        },
        "parameterValueType": "Alternative"
    }
}

بعد تعريف المورد هذا Microsoft.Web/connections، تأكد من إضافة نهج وصول يحدد تعريف مورد لكل اتصال API وقدم المعلومات التالية:

المعلمة	‏‏الوصف‬
<اسم الاتصال>	اسم اتصال API الخاص بك، على سبيل المثال، `azureblob`
<معرّف العنصر>	معرف الكائن لهوية Microsoft Entra، المحفوظة مسبقا من تسجيل التطبيق
<معرف المستأجر>	معرف المستأجر لهوية Microsoft Entra، المحفوظة مسبقا من تسجيل التطبيق الخاص بك

{
   "type": "Microsoft.Web/connections/accessPolicies",
   "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
   "name": "[concat('<connection-name>','/','<object-ID>')]",
   "location": "<location>",
   "dependsOn": [
      "[resourceId('Microsoft.Web/connections', parameters('connection_name'))]"
   ],
   "properties": {
      "principal": {
         "type": "ActiveDirectory",
         "identity": {
            "objectId": "<object-ID>",
            "tenantId": "<tenant-ID>"
         }
      }
   }
}

لمزيد من المعلومات، راجع Microsoft.Web/connections/accesspolicies (قالب ARM) .

إعداد التحكم المتقدم في مصادقة اتصال واجهة برمجة التطبيقات

عندما يستخدم سير العمل اتصال API، الذي يتم إنشاؤه بواسطة موصل مدار مثل Office 365 Outlook وAzure Key Vault وما إلى ذلك، تتصل خدمة Azure Logic Apps بالمورد الهدف، مثل حساب البريد الإلكتروني وخزنة المفاتيح وما إلى ذلك، باستخدام اتصالين:

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

تم إعداد الاتصال #1 مع المصادقة لمخزن الرمز المميز الداخلي.
تم إعداد الاتصال رقم 2 مع مصادقة المورد الهدف.

في مورد تطبيق منطق الاستهلاك، يتم تجريد الاتصال رقم 1 منك دون أي خيارات تكوين. في نوع مورد تطبيق المنطق القياسي، لديك المزيد من التحكم في تطبيق المنطق الخاص بك. بشكل افتراضي، يتم إعداد الاتصال #1 تلقائيا لاستخدام الهوية المعينة من قبل النظام.

ومع ذلك، إذا كان السيناريو الخاص بك يتطلب تحكما أدق في مصادقة اتصالات واجهة برمجة التطبيقات، يمكنك اختياريا تغيير مصادقة الاتصال #1 من الهوية الافتراضية المعينة من قبل النظام إلى أي هوية معينة من قبل المستخدم قمت بإضافتها إلى تطبيق المنطق الخاص بك. تنطبق هذه المصادقة على كل اتصال API، بحيث يمكنك خلط الهويات المعينة من قبل النظام والمخصصة من قبل المستخدم عبر اتصالات مختلفة لنفس المورد الهدف.

في ملف Standard logic app connections.json، الذي يخزن معلومات حول كل اتصال API، يحتوي كل تعريف اتصال على قسمين authentication، على سبيل المثال:

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

يعين القسم الأول authentication الاتصال رقم 1. يصف هذا القسم المصادقة المستخدمة للتواصل مع مخزن الرمز المميز الداخلي. في الماضي، تم تعيين هذا القسم دائمًا إلى ManagedServiceIdentity لتطبيق يتم نشره في Azure وليس لديه خيارات قابلة للتكوين.
يعين القسم الثاني authentication الاتصال رقم 2. يصف هذا القسم إمكانية اختلاف المصادقة المستخدمة للتواصل مع المورد الهدف، استنادا إلى نوع المصادقة الذي تحدده لهذا الاتصال.

لماذا تغيير المصادقة لمخزن الرمز المميز؟

في بعض السيناريوهات، قد تحتاج إلى مشاركة واستخدام نفس اتصال واجهة برمجة التطبيقات عبر تطبيقات منطقية متعددة، ولكن لا تضيف الهوية المعينة من قبل النظام لكل تطبيق منطقي إلى نهج الوصول للمورد الهدف.

في سيناريوهات أخرى، قد لا ترغب في إعداد الهوية المعينة من قبل النظام على تطبيق المنطق الخاص بك بالكامل، حتى تتمكن من تغيير المصادقة إلى هوية معينة من قبل المستخدم وتعطيل الهوية المعينة من قبل النظام تماما.

تغيير المصادقة لمخزن الرمز المميز

في مدخل Microsoft Azure، افتح مورد تطبيق المنطق القياسي.
في قائمة الموارد، ضمن Workflows، حدد Connections.
في جزء Connections، حدد JSON View.
في محرر JSON، ابحث عن managedApiConnections القسم الذي يحتوي على اتصالات واجهة برمجة التطبيقات عبر جميع مهام سير العمل في مورد تطبيق المنطق الخاص بك.

ابحث عن الاتصال حيث تريد إضافة هوية مدارة معينة من قبل المستخدم. على سبيل المثال، افترض أن سير العمل الخاص بك يحتوي على اتصال Azure Key Vault:

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

في تعريف الاتصال، أكمل الخطوات التالية:

اعثر على القسم الأول authentication. إذا لم تكن هناك خاصية identity موجودة بالفعل في هذا القسم authentication، فإن تطبيق المنطق يستخدم ضمنيًا الهوية المعينة من قبل النظام.
أضف خاصية identity باستخدام المثال في هذه الخطوة.
تعيين قيمة الخاصية إلى معرف المورد للهوية المعينة من قبل المستخدم.

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

في مدخل Microsoft Azure، انتقل إلى المورد الهدف، وامنح حق الوصول إلى الهوية المدارة المعينة من قبل المستخدم، بناء على احتياجات المورد الهدف.

على سبيل المثال، بالنسبة إلى Azure Key Vault، أضف الهوية إلى نهج الوصول إلى مخزن المفاتيح. بالنسبة إلى Azure Blob Storage، قم بتعيين الدور الضروري للهوية إلى حساب التخزين.

تعطيل الهوية المدارة

للتوقف عن استخدام الهوية المدارة للمصادقة، قم أولا بإزالة وصول الهوية إلى المورد الهدف. بعد ذلك، على مورد تطبيق المنطق الخاص بك، قم بإيقاف تشغيل الهوية المعينة من قبل النظام أو قم بإزالة الهوية المعينة من قبل المستخدم.

عند تعطيل الهوية المدارة على مورد تطبيق المنطق الخاص بك، يمكنك إزالة إمكانية تلك الهوية لطلب الوصول إلى موارد Azure حيث كان للهوية حق الوصول.

إشعار

إذا قمت بتعطيل الهوية المعينة من قبل النظام، فلن تعمل أي وجميع الاتصالات المستخدمة من قبل مهام سير العمل في سير عمل تطبيق المنطق هذا في وقت التشغيل، حتى إذا قمت بتمكين الهوية مرة أخرى على الفور. يحدث هذا السلوك لأن تعطيل الهوية يؤدي إلى حذف معرف الكائن. في كل مرة تقوم فيها بتمكين الهوية، يقوم Azure بإنشاء الهوية بمعرف كائن مختلف وفريد. لحل هذه المشكلة، تحتاج إلى إعادة إنشاء الاتصالات بحيث تستخدم معرف الكائن الحالي للهوية الحالية المعينة من قبل النظام.

حاول تجنب تعطيل الهوية المعينة من قبل النظام قدر الإمكان. إذا كنت تريد إزالة وصول الهوية إلى موارد Azure، فقم بإزالة تعيين دور الهوية من المورد الهدف. إذا قمت بحذف مورد تطبيق المنطق الخاص بك، يقوم Azure تلقائيا بإزالة الهوية المدارة من معرف Microsoft Entra.

تغطي الخطوات الواردة في هذا القسم استخدام مدخل Microsoft Azure وقالب Azure Resource Manager (قالب ARM). بالنسبة إلى Azure PowerShell وAzure CLI وAzure REST API، راجع الوثائق التالية:

الأداة	‏‏الوثائق
Azure PowerShell	1. إزالة تعيين الدور. 2. حذف الهوية التي يعينها المستخدم.
Azure CLI	1. إزالة تعيين الدور. 2. حذف الهوية التي يعينها المستخدم.
Azure REST API	1. إزالة تعيين الدور. 2. حذف الهوية التي يعينها المستخدم.

تعطيل الهوية المدارة في مدخل Microsoft Azure

لإزالة الوصول إلى الهوية المدارة، قم بإزالة تعيين دور الهوية من المورد الهدف، ثم قم بتعطيل الهوية المدارة.

إزالة تعيين الدور

تزيل الخطوات التالية الوصول إلى المورد الهدف من الهوية المدارة:

في مدخل Microsoft Azure، انتقل إلى مورد Azure الهدف حيث تريد إزالة الوصول للهوية المدارة.
من قائمة المورد الهدف، حدد Access control (IAM). ضمن شريط الأدوات، حدد Role assignments.
في قائمة الأدوار، حدد الهويات المدارة التي تريد إزالتها. على شريط الأدوات، حدد إزالة.

تلميح

إذا تم تعطيل الخيار إزالة، فمن المحتمل ألا يكون لديك أذونات. لمزيد من المعلومات حول الأذونات التي تتيح لك إدارة الأدوار للموارد، راجع أذونات دور مسؤول istrator في معرف Microsoft Entra.

تعطيل الهوية المدارة على مورد تطبيق المنطق

في مدخل Microsoft Azure، افتح مورد التطبيق المنطقي.
في قائمة التنقل في تطبيق المنطق، ضمن الإعدادات، حدد الهوية، ثم اتبع الخطوات الخاصة بهويتك:
- حدد النظام المعين>تشغيل>حفظ. عندما يطالبك Azure بالتأكيد، حدد نعم.
- حدد المستخدم المعين والهوية المدارة، ثم حدد إزالة. عندما يطالبك Azure بالتأكيد، حدد نعم.

تعطيل الهوية المدارة في قالب ARM

إذا قمت بإنشاء الهوية المدارة لتطبيق المنطق باستخدام قالب ARM، فقم بتعيين الخاصية التابعة type للكائن identity إلى None.

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

الخطوات التالية

الوصول الآمن والبيانات في Azure Logic Apps

مصادقة الوصول والاتصالات إلى موارد Azure باستخدام الهويات المدارة في Azure Logic Apps

تطبيق منطق "الاستهلاك" مقابل تطبيق منطق "قياسي"

حيث يمكنك استخدام هوية مدارة

المتطلبات الأساسية

تمكين الهوية المعينة من قبل النظام في مدخل Microsoft Azure

تمكين الهوية المعينة من قبل النظام في قالب ARM

إنشاء هوية معينة من قبل المستخدم في مدخل Azure

إضافة هوية معينة من قبل المستخدم إلى تطبيق المنطق في مدخل Microsoft Azure

إنشاء هوية معينة من قبل المستخدم في قالب ARM

منح حق الوصول إلى الموارد للهوية

تعيين الوصول المستند إلى دور الهوية المدارة في مدخل Microsoft Azure

إنشاء نهج الوصول في مدخل Microsoft Azure

مصادقة الوصول باستخدام الهوية المدارة

مثال: مصادقة المشغل أو الإجراء المضمن بهوية مدارة

مثال: مصادقة مشغل الموصل المدار أو الإجراء باستخدام هوية مدارة

تعريف مورد تطبيق المنطق والاتصالات التي تستخدم هوية مدارة

قالب ARM لاتصالات واجهة برمجة التطبيقات والهويات المدارة

مصادقة أحادية

مصادقة متعددة

إعداد التحكم المتقدم في مصادقة اتصال واجهة برمجة التطبيقات

لماذا تغيير المصادقة لمخزن الرمز المميز؟

تغيير المصادقة لمخزن الرمز المميز

تعطيل الهوية المدارة

تعطيل الهوية المدارة في مدخل Microsoft Azure

إزالة تعيين الدور

تعطيل الهوية المدارة على مورد تطبيق المنطق

تعطيل الهوية المدارة في قالب ARM

الخطوات التالية

الموارد الإضافية