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

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

إذا كنت ترغب في تجنب توفير بيانات الاعتماد أو البيانات السرية أو الرموز المميزة ل Microsoft Entra وتخزينها وإدارتها، يمكنك استخدام هوية مدارة لمصادقة الوصول أو الاتصالات من سير عمل تطبيق المنطق إلى موارد Microsoft Entra المحمية. في Azure Logic Apps، تدعم بعض عمليات الموصل استخدام هوية مدارة عندما يتعين عليك مصادقة الوصول إلى الموارد المحمية بواسطة معرف Microsoft Entra. يدير Azure هذه الهوية ويساعد على الحفاظ على أمان معلومات المصادقة بحيث لا تضطر إلى إدارة هذه المعلومات الحساسة. للمزيد من المعلومات، راجعما المقصود بالهويات المُدارة لموارد Microsoft 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. إذا لم يكن لديك اشتراك، فيجب التسجيل للحصول على حساب Azure مجاني. يجب أن تستخدم كل من الهوية المدارة ومورد Azure الهدف حيث تحتاج إلى الوصول نفس اشتراك Azure.

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

  • مورد التطبيق المنطقي وسير العمل حيث تريد استخدام المشغل أو الإجراءات التي تدعم الهويات المدارة.

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

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

تطبيق المنطق البيئة دعم الهوية المدارة
الاستهلاك‬ - تطبيقات 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 استخدام هوية مدارة للمصادقة. توفر الجداول التالية عينة تحديد فقط. للحصول على قائمة أكثر اكتمالا، راجع الوثائق التالية:

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

نوع الموصل الموصلات المدعومة
مضمّن - إدارة واجهة برمجة تطبيقات Azure
- Azure App Services
- Azure Functions
- HTTP
- HTTP + Webhook

ملاحظة: يمكن لعمليات HTTP مصادقة الاتصالات بحسابات Azure Storage خلف جدران حماية Azure باستخدام الهوية المعينة من قبل النظام. ومع ذلك، لا تدعم عمليات HTTP الهوية المعينة من قبل المستخدم لمصادقة نفس الاتصالات.
مُدار - Azure App Service
- Azure Automation
- Azure Blob Storage
- مثيل حاوية Azure
- Azure Cosmos DB
- Azure Data Explorer
- Azure Data Factory
- Azure Data Lake
- Azure Digital Twins
- Azure Event Grid
- مراكز أحداث Azure
- Azure IoT Central V2
- Azure Key Vault
-سجلات Azure Monitor
- قوائم انتظار Azure
- Azure Resource Manager
- ناقل خدمة Azure
- Azure Sentinel
- Azure Table Storage
- Azure VM
- SQL Server

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

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

  1. في مدخل Microsoft Azure، افتح مورد تطبيق Consumption logic.

  2. في قائمة logic app، ضمن Settings، حدد Identity.

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

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

    إشعار

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

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

    تظهر لقطة الشاشة تطبيق منطق الاستهلاك وصفحة الهوية ومعرف العنصر للهوية المعينة من قبل النظام.

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

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

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

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

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

"identity": {
   "type": "SystemAssigned",
   "principalId": "<principal-ID>",
   "tenantId": "<Entra-tenant-ID>"
}
خاصية (JSON) قيمة ‏‏الوصف
principalId <principal-ID> المعرف الفريد العمومي (GUID) للكائن الأساسي للخدمة للهوية المدارة التي تمثل تطبيق المنطق الخاص بك في مستأجر Microsoft Entra. يظهر هذا المعرف الفريد العمومي في بعض الأحيان ك "معرف كائن" أو معرف عنصر.
tenantId <Microsoft-Entra-ID-tenant-ID> المعرف الفريد العمومي (GUID) الذي يمثل مستأجر Microsoft Entra حيث أصبح تطبيق المنطق الآن عضوا. داخل مستأجر Microsoft Entra، يكون لمدير الخدمة نفس اسم مثيل تطبيق المنطق.

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

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

  1. في مربع البحث في مدخل Microsoft Azure، أدخل الهويات المدارة. من قائمة النتائج، حدد الهويات المدارة.

    تظهر لقطة الشاشة مدخل Microsoft Azure مع خيار محدد يسمى الهويات المدارة.

  2. في شريط أدوات صفحة الهويات المدارة ، حدد إنشاء.

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

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

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

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

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

  1. في مدخل Microsoft Azure، افتح مورد تطبيق Consumption logic.

  2. في قائمة logic app، ضمن Settings، حدد Identity.

  3. في صفحة Identity ، حدد User assigned، ثم حدد Add.

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

  4. في جزء إضافة هوية مدارة معينة من قبل المستخدم، اتبع الخطوات التالية:

    1. من قائمة تحديد اشتراك، حدد اشتراك Azure الخاص بك.

    2. من القائمة التي تحتوي على جميع الهويات المدارة في اشتراكك، حدد الهوية المعينة من قبل المستخدم التي تريدها. لتصفية القائمة، في مربع البحث الهويات المدارة المعينة من قبل المستخدم، أدخل اسم الهوية أو مجموعة الموارد.

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

    3. عندما تنتهي، حدد إضافة.

      إشعار

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

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

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

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

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

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

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

  • كائن هوية مع تعيين خاصية النوع إلى UserAssigned

  • كائن userAssignedIdentities تابع يحدد المورد والاسم المعينين من قبل المستخدم

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

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

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

{
   "$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 الهدف حيث تريد استخدام الهوية. تختلف طريقة إعداد الوصول استنادا إلى المورد الهدف.

إشعار

عندما يكون للهوية المدارة حق الوصول إلى مورد 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، إنشاء نهج وصول لديه الأذونات المناسبة على المورد الهدف لتلك الهوية.

  1. في مدخل Microsoft Azure، افتح المورد الذي تريد استخدام الهوية فيه.

  2. في قائمة الموارد، حدد Access control (IAM)>Add>Add role assignment.

    إشعار

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

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

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

  4. بعد ذلك، اختر الهوية المدارة حيث تريد تعيين الدور. ضمن تعيين الوصول إلى، حدد الهوية> المدارةإضافة أعضاء.

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

    نوع مثيل خدمة 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، تعيين هذه الهوية لدور لديه الأذونات المناسبة على المورد الهدف.

  1. في مدخل Microsoft Azure، افتح المورد الذي تريد استخدام الهوية فيه. يستخدم هذا المثال مخزن مفاتيح Azure كمورد مستهدف.

  2. في قائمة الموارد، حدد Access policies>Create، الذي يفتح جزء Create an access policy.

    إشعار

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

    تظهر لقطة الشاشة مدخل Microsoft Azure ومثال key vault مع جزء مفتوح يسمى Access policies.

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

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

    تظهر لقطة الشاشة علامة تبويب الأذونات مع أذونات القائمة المحددة.

  4. عندما تصبح مستعداً، حدد "Next". في علامة التبويب Principal، ابحث عن الهوية المدارة وحددها، وهي هوية معينة من قبل المستخدم في هذا المثال.

  5. تخطي خطوة التطبيق الاختيارية، وحدد التالي، وإنهاء إنشاء نهج الوصول.

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

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

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

هام

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

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

  1. في مدخل Microsoft Azure، افتح مورد تطبيق Consumption logic.

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

    إشعار

    لا تدعم جميع عمليات الموصل السماح لك بإضافة نوع مصادقة. لمزيد من المعلومات، راجع أنواع المصادقة للمشغلات والإجراءات التي تدعم المصادقة.

  3. في المشغل أو الإجراء الذي أضفته، اتبع الخطوات التالية:

    • عمليات الموصل المضمنة التي تدعم مصادقة الهوية المدارة

      تستمر هذه الخطوات باستخدام إجراء HTTP كمثال.

      1. من قائمة Advanced parameters، أضف خاصية Authentication، إذا لم تظهر الخاصية بالفعل.

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

        الآن، تظهر كل من الخاصية Authentication وقائمة Authentication Type في الإجراء.

        تظهر لقطة الشاشة قسم المعلمات المتقدمة مع خاصية المصادقة المضافة وقائمة نوع المصادقة.

      2. من قائمة نوع المصادقة، حدد الهوية المدارة.

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

        يعرض قسم المصادقة الآن الخيارات التالية:

        • قائمة هوية مدارة من حيث يمكنك تحديد هوية مدارة معينة

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

      3. من قائمة الهوية المدارة، حدد الهوية التي تريد استخدامها، على سبيل المثال:

        تظهر لقطة الشاشة قسم المصادقة مع قائمة نوع المصادقة وخاصية الجماعة المستهدفة.

        إشعار

        الخيار الافتراضي المحدد هو الهوية المدارة المعينة من قبل النظام، حتى عندما لا يكون لديك أي هويات مدارة ممكنة.

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

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

    • عمليات الموصل المدارة التي تدعم مصادقة الهوية المدارة

      1. في جزء Create الاتصال ion، من قائمة Authentication، حدد Managed Identity، على سبيل المثال:

        تظهر لقطة الشاشة سير عمل الاستهلاك مع إجراء Azure Resource Manager والخيار المحدد للهوية المدارة.

      2. في الجزء التالي، بالنسبة إلى اسم الاتصال ion، قم بتوفير اسم لاستخدامه للاتصال.

      3. بالنسبة لنوع المصادقة، اختر أحد الخيارات التالية استنادًا إلى الموصل المدار:

        • مصادقة واحدة: تدعم هذه الموصلات نوع مصادقة واحدا فقط، وهو الهوية المدارة في هذه الحالة.

          1. من قائمة الهوية المدارة، حدد الهوية المدارة الممكنة حاليا.

          2. عندما تصبح جاهزا، حدد إنشاء جديد.

        • المصادقة المتعددة: تدعم هذه الموصلات أنواع مصادقة متعددة، ولكن يمكنك تحديد نوع واحد فقط واستخدامه في كل مرة.

          تستمر هذه الخطوات باستخدام إجراء Azure Blob Storage كمثال.

          1. من قائمة نوع المصادقة، حدد Logic Apps Managed Identity.

            تظهر لقطة الشاشة سير عمل الاستهلاك ومربع إنشاء الاتصال والخيار المحدد ل Logic Apps Managed Identity.

          2. عندما تصبح جاهزا، حدد إنشاء جديد.

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

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

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

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

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

هام

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

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

الخاصية المطلوب قيمة المثال ‏‏الوصف
Uri ‏‏نعم‬ https://<storage-account-name>/<folder-name>/{name} معرف المورد لملف Azure Blob Storage في بيئة Azure Global (العامة)، والذي يستخدم بناء الجملة هذا
الطريقة ‏‏نعم‬ PUT أسلوب HTTP الذي تستخدمه عملية Snapshot Blob
رؤوس بالنسبة إلى تخزين Azure x-ms-blob-type = BlockBlob

x-ms-version = 2024-05-05

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 اسم معلمة الاستعلام وقيمتها للعملية.
  1. على مصمم سير العمل، أضف أي مشغل تريده، ثم أضف إجراء HTTP .

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

    تظهر لقطة الشاشة مدخل Microsoft Azure وسير عمل الاستهلاك وإجراء HTTP الذي تم إعداده للوصول إلى الموارد.

  2. في إجراء HTTP ، أضف خاصية Authentication . من قائمة Advanced parameters، حدد Authentication.

    تظهر لقطة الشاشة سير عمل الاستهلاك مع إجراء HTTP وقائمة المعلمات المتقدمة المفتوحة مع خاصية محددة تسمى المصادقة.

    يظهر قسم المصادقة الآن في إجراء HTTP الخاص بك.

    إشعار

    لا تدعم جميع المشغلات والإجراءات السماح لك بإضافة نوع مصادقة. لمزيد من المعلومات، راجع أنواع المصادقة للمشغلات والإجراءات التي تدعم المصادقة.

  3. من قائمة نوع المصادقة، حدد الهوية المدارة.

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

  4. من قائمة الهوية المدارة، حدد من الخيارات المتوفرة استنادا إلى السيناريو الخاص بك.

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

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

    • إذا قمت بإعداد الهوية المعينة من قبل المستخدم، فحدد هذه الهوية.

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

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

  5. في بعض المشغلات والإجراءات، تظهر الخاصية Audience بحيث يمكنك تعيين معرف المورد لمورد أو خدمة Azure الهدف.

    على سبيل المثال، لمصادقة الوصول إلى مورد Key Vault في سحابة Azure العمومية، يجب تعيين الخاصية Audience إلى معرف المورد التالي بالضبط : https://vault.azure.net

    إذا لم تقم بتعيين الخاصية Audience، بشكل افتراضي، تستخدم https://management.azure.com/ الخاصية Audience معرف المورد، وهو معرف المورد ل Azure Resource Manager.

    هام

    تأكد من تطابق معرف المورد الهدف تماما مع القيمة التي يتوقعها معرف Microsoft Entra. وإلا، فقد تحصل على 400 Bad Request خطأ أو خطأ 401 Unauthorized . لذلك، إذا كان معرف المورد يتضمن أي شرطة مائلة زائدة، فتأكد من تضمينها. وإلا، فلا تقم بتضمينها.

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

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

    تظهر لقطة الشاشة سير عمل الاستهلاك وإجراء HTTP مع تعيين خاصية Audience إلى معرف المورد الهدف.

    لمزيد من المعلومات حول تخويل الوصول باستخدام معرف Microsoft Entra لتخزين Azure، راجع الوثائق التالية:

  6. تابع إنشاء سير العمل بالطريقة التي تريدها.

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

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

  1. على مصمم سير العمل، أضف إجراء Azure Resource Manager المسمى Read a resource.

  2. في جزء Create الاتصال ion، من قائمة Authentication، حدد Managed Identity، ثم حدد Sign in.

    إشعار

    في الموصلات الأخرى، تعرض قائمة نوع المصادقة Logic Apps Managed Identity بدلا من ذلك، لذا حدد هذا الخيار.

    تظهر لقطة الشاشة سير عمل الاستهلاك، وإجراء Azure Resource Manager، وقائمة المصادقة المفتوحة، والخيار المحدد للهوية المدارة.

  3. أدخل اسما للاتصال، وحدد الهوية المدارة التي تريد استخدامها.

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

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

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

    إشعار

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

  4. عندما تصبح جاهزا، حدد إنشاء جديد.

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

  6. تابع إنشاء سير العمل بالطريقة التي تريدها.

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

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

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

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

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

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

"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 لاتصالات واجهة برمجة التطبيقات والهويات المدارة

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

في قالب ARM، يختلف تعريف مورد الموصل الأساسي استنادا إلى ما إذا كان لديك مورد Consumption أو Standard logic app وما إذا كان الموصل يعرض خيارات المصادقة المفردة أو المصادقة المتعددة.

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

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

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

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

  • تم تعيين الخاصية parameterValueType على Alternative.

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

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

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

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

  • يتضمن الكائن parameterValueSet خاصية name تم تعيينها إلى managedIdentityAuth وخاصية values تم تعيينها إلى كائن فارغ.

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

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

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

يوضح الرسم التخطيطي المفاهيمي الاتصال الأول بالمصادقة بين تطبيق المنطق ومخزن الرمز المميز بالإضافة إلى الاتصال الثاني بين مخزن الرمز المميز والمورد الهدف.

  • تم إعداد الاتصال #1 مع المصادقة لمخزن الرمز المميز الداخلي.

  • تم إعداد الاتصال رقم 2 مع مصادقة المورد الهدف.

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

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

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

"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>"
}
  • يعين القسم الأول authentication الاتصال رقم 1.

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

  • يعين القسم الثاني authentication الاتصال رقم 2.

    يصف هذا القسم إمكانية اختلاف المصادقة المستخدمة للتواصل مع المورد الهدف، استنادا إلى نوع المصادقة الذي تحدده لهذا الاتصال.

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

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

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

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

  1. في مدخل Microsoft Azure، افتح مورد تطبيق المنطق القياسي.

  2. في قائمة الموارد، ضمن Workflows، حدد Connections.

  3. في جزء الاتصال ions، حدد JSON View.

    لقطة شاشة تعرض مدخل Microsoft Azure، ومورد تطبيق المنطق القياسي، وجزء الاتصال ions مع تحديد JSON View.

  4. في محرر JSON، ابحث عن managedApiConnections القسم الذي يحتوي على اتصالات واجهة برمجة التطبيقات عبر جميع مهام سير العمل في مورد تطبيق المنطق الخاص بك.

  5. ابحث عن الاتصال حيث تريد إضافة هوية مدارة معينة من قبل المستخدم.

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

    "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. في تعريف الاتصال، أكمل الخطوات التالية:

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

    2. أضف خاصية identity باستخدام المثال في هذه الخطوة.

    3. تعيين قيمة الخاصية إلى معرف المورد للهوية المعينة من قبل المستخدم.

    "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. في مدخل 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. حذف الهوية التي يعينها المستخدم.

لمزيد من المعلومات، راجع إزالة تعيينات دور Azure.

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

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

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

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

  1. في مدخل Microsoft Azure، انتقل إلى مورد Azure الهدف حيث تريد إزالة الوصول للهوية المدارة.

  2. من قائمة المورد الهدف، حدد Access control (IAM). ضمن شريط الأدوات، حدد Role assignments.

  3. في قائمة الأدوار، حدد الهويات المدارة التي تريد إزالتها. على شريط الأدوات، حدد إزالة.

    تلميح

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

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

  1. في مدخل Microsoft Azure، افتح مورد التطبيق المنطقي.

  2. في قائمة موارد تطبيق المنطق، ضمن الإعدادات، حدد الهوية، ثم اتبع الخطوات الخاصة بهويتك:

    • حدد النظام المعين>تشغيل>حفظ. عندما يطالبك Azure بالتأكيد، حدد نعم.

    • حدد المستخدم المعين والهوية المدارة، ثم حدد إزالة. عندما يطالبك Azure بالتأكيد، حدد نعم.

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

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

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