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

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

في مهام سير عمل تطبيق المنطق، تدعم بعض المشغلات والإجراءات استخدام هوية مدارة لمصادقة الوصول إلى الموارد المحمية بواسطة Azure Active Directory (Azure AD). عند استخدام هوية مدارة لمصادقة اتصالك، لا يتعين عليك توفير بيانات الاعتماد أو البيانات السرية أو الرموز المميزة Azure AD. يدير 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 إنشاء هوية يُعينها المستخدم

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

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

تطبيق المنطق البيئة دعم الهوية المدارة
Consumption - تطبيقات المنطق Azure متعددة المستأجرين

- بيئة خدمة التكامل (ISE)
- يمكن لتطبيق المنطق الخاص بك تمكين الهوية المعينة من قبل النظام أو الهوية المعينة من قبل المستخدم.

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

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

- بيئة خدمة التطبيق الإصدار 3 (ASEv3)

- تمكين Azure Arc لـ Logic Apps
- يمكنك تمكين كل من الهوية المعينة من قبل النظام، والتي يتم تمكينها افتراضيا، والهوية المعينة من قبل المستخدم في نفس الوقت.

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

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

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

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

يمكن فقط لعمليات موصل مضمنة ومدارة محددة تدعم Azure AD Open Authentication (Azure AD OAuth) استخدام هوية مدارة للمصادقة. يوفر الجدول التالي عينة تحديد فقط. للحصول على قائمة أكثر اكتمالاً، راجع أنواع المصادقة للمشغلات والإجراءات التي تدعم المصادقةوخدمات Azure التي تدعم مصادقة Azure AD مع الهويات المدارة.

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

نوع الموصل الموصلات المدعومة
الأجزاء المدمجة - إدارة Azure APIM
- Azure App Services
- Azure Functions
- HTTP
- HTTP + Webhook

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

مُدار - Azure AD Identity Protection
- خدمة تطبيق Azure
- أتمتة Azure
- تخزين Azure Blob
- مثيل حاوية Azure
- قاعدة بيانات Azure Cosmos
- مستكشف بيانات Azure
- Azure Data Factory
- Azure Data Lake
- شبكة أحداث Azure
- مراكز أحداث Azure
- Azure IoT Central V2
- Azure IoT Central V3
- Azure Key Vault
- Azure Log Analytics
- قوائم انتظار Azure
- Azure Resource Manager
- ناقل خدمة Azure
- Azure Sentinel
- جهاز Azure ظاهري
- HTTP مع Microsoft Azure Active Directory
- SQL Server

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

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

  1. في مدخل Microsoft Azure، انتقل إلى مورد تطبيق المنطق الخاص بك.

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

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

    لقطة شاشة تعرض مدخل Microsoft Azure مع جزء

    ملاحظة

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

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

    لقطة شاشة تظهر جزء

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

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

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

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

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

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

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

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

  1. في صندوق بحث مدخل Microsoft Azure، أدخل managed identities. حدد الهويات المُدارة .

    Screenshot showing Azure portal with

  2. في جزء الهويات المدارة، حدد إنشاء.

    Screenshot showing

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

    Screenshot showing

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

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

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

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

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

  3. في جزء Identity، حدد User assigned>Add.

    Screenshot showing Consumption logic app and

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

    1. من قائمة الاشتراك، حدد اشتراك Azure، إذا لم يكن محددا بالفعل.

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

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

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

      ملاحظة

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

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

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

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

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

ملاحظة

عندما يكون للهوية المدارة حق الوصول إلى مورد 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.

    ملاحظة

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

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

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

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

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

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

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

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

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

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

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

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

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

    ملاحظة

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

    Screenshot showing the Azure portal and key vault example with

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

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

    Screenshot showing

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

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

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

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

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

هام

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

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

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

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

    ملاحظة

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

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

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

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

        لقطة شاشة تعرض المثال الإجراء المضمن مع فتح قائمة

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

        لقطة شاشة تعرض المثال الإجراء المضمن مع فتح قائمة

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

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

      1. في صفحة تحديد المستأجر، حدد الاتصال بالهوية المدارة، على سبيل المثال:

        لقطة شاشة تظهر إجراء Azure Resource Manager و

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

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

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

          لقطة شاشة تعرض صفحة اسم الاتصال والهوية المدارة الوحيدة المحددة في Consumption.

        • المصادقة المتعددة: تعرض هذه الموصلات أنواع مصادقة متعددة، ولكن لا يزال بإمكانك تحديد نوع واحد فقط. من قائمة نوع المصادقة، حدد Logic Apps Managed Identity>Create، على سبيل المثال:

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

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

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

يمكن لمشغل أو إجراء 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:

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

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

    لقطة شاشة تظهر سير عمل Consumption مع إجراء HTTP وقائمة

    ملاحظة

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

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

    لقطة شاشة تظهر سير عمل الاستهلاك مع إجراء HTTP و

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

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

      لقطة شاشة تظهر سير عمل الاستهلاك مع إجراء HTTP وملكية

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

      لقطة شاشة تظهر سير عمل الاستهلاك مع إجراء HTTP وملكية

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

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

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

    هام

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

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

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

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

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

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

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

  1. بعد إضافة الإجراء إلى سير العمل وتحديد مستأجر Azure AD، حدد الاتصال بالهوية المدارة.

    لقطة شاشة تظهر إجراء Azure Resource Manager و

  2. في صفحة اسم الاتصال، قم بتوفير اسم للاتصال، وحدد الهوية المدارة التي تريد استخدامها.

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

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

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

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

    ملاحظة

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

  3. عندما تكون مستعداً، حدد Create.

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

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

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

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

في مورد Logic App (Consumption)، يتم حفظ تكوين الاتصال في كائن تعريف 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}"
         }
      }
   }
}

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

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

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

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

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

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

  • تم تعيين الخاصية apiVersion على 2016-06-01.
  • يتم تعيين الخاصية kind إلى V1 لتطبيق منطق الاستهلاك.
  • تم تعيين الخاصية parameterValueType على Alternative.
{
    "type": "Microsoft.Web/connections",
    "name": "[variables('connections_azureautomation_name')]",
    "apiVersion": "2016-06-01",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureautomation')]"
        },
        "customParameterValues": {},
        "displayName": "[variables('connections_azureautomation_name')]",
        "parameterValueType": "Alternative"
    }
},

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

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

  • تم تعيين الخاصية apiVersion على 2018-07-01-preview.
  • يتم تعيين الخاصية kind إلى V1 لتطبيق منطق الاستهلاك.
  • يتضمن الكائن parameterValueSet خاصية name تم تعيينها إلى managedIdentityAuth وخاصية values تم تعيينها إلى كائن فارغ.
{
    "type": "Microsoft.Web/connections",
    "apiVersion": "2018-07-01-preview",
    "name": "[variables('connections_azureblob_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues":{},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureblob')]"
        },
        "customParameterValues": {},
        "displayName": "[variables('connections_azureblob_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        }
    }
}

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

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

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

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

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

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

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

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

  3. في جزء Connections، حدد JSON View.

    Screenshot showing the Azure portal, Standard logic app resource,

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

  5. ابحث عن الاتصال حيث تريد إضافة هوية مدارة معينة من قبل المستخدم. على سبيل المثال، افترض أن سير العمل الخاص بك يحتوي على اتصال 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>"
    }
    
  6. في تعريف الاتصال، أكمل الخطوات التالية:

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

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

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

    "keyvault": {
       "api": {
          "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/keyvault"
       },
       "authentication": {
          "type": "ManagedServiceIdentity",
          // Add "identity" property here
          "identity": "/subscriptions/{Azure-subscription-ID}/resourcegroups/{resource-group-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{identity-resource-ID}" 
       },
       "connection": {
          "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-name>"
       },
       "connectionProperties": {
          "authentication": {
             "audience": "https://vault.azure.net",
             "type": "ManagedServiceIdentity"
          }
       },
       "connectionRuntimeUrl": "<connection-runtime-URL>"
    }
    
  7. في مدخل Microsoft Azure، انتقل إلى المورد الهدف، وامنح حق الوصول إلى الهوية المدارة المعينة من قبل المستخدم، بناء على احتياجات المورد الهدف.

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

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

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

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

ملاحظة

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

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

تغطي الخطوات الواردة في هذا القسم استخدام مدخل 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

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

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

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

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

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

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

    تلميح

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

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

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

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

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

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

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

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

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

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