مشاركة عبر

تكوين App Service أو تطبيق Azure Functions لاستخدام تسجيل الدخول إلى Microsoft Entra

  • مقالة

إشعار

بدءا من 1 يونيو 2024، سيكون لجميع تطبيقات App Service التي تم إنشاؤها حديثا خيار إنشاء اسم مضيف افتراضي فريد مع اصطلاح تسمية .<app-name><region>-<random-hash>..azurewebsites.net لن تتغير أسماء التطبيقات الموجودة.

مثال: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

لمزيد من المعلومات، راجع اسم المضيف الافتراضي الفريد لمورد App Service.

حدد موفر مصادقة آخر للانتقال إليه.

توضح هذه المقالة كيفية تكوين المصادقة ل Azure App Service أو Azure Functions بحيث يقوم تطبيقك بتسجيل دخول المستخدمين باستخدام النظام الأساسي للهويات في Microsoft (Microsoft Entra) كموفر المصادقة.

اختيار مستأجر لتطبيقك ومستخدميه

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

  1. سجل الدخول إلى مدخل Azure والانتقال إلى تطبيقك.

  2. في القائمة اليسرى لتطبيقك، حدد Authentication، ثم حدد Add identity provider.

  3. في صفحة إضافة موفر هوية، حدد Microsoft كموفر الهوية لتسجيل الدخول إلى هويات Microsoft وMicrosoft Entra.

  4. بالنسبة إلى نوع المستأجر، حدد تكوين القوى العاملة (المستأجر الحالي) للموظفين وضيوف الأعمال أو حدد التكوين الخارجي للمستهلكين وعملاء الأعمال.

اختر تسجيل التطبيق

يمكن لميزة App Service Authentication إنشاء تسجيل تطبيق لك تلقائيا أو يمكنك استخدام تسجيل قمت أنت أو مسؤول دليل بإنشائه بشكل منفصل.

قم بإنشاء تسجيل تطبيق جديد تلقائيا، إلا إذا كنت بحاجة إلى إنشاء تسجيل تطبيق بشكل منفصل. يمكنك تخصيص تسجيل التطبيق في مركز إدارة Microsoft Entra لاحقا إذا أردت ذلك.

الحالات التالية هي الحالات الأكثر شيوعا لاستخدام تسجيل تطبيق موجود:

  • لا يملك حسابك أذونات لإنشاء تسجيلات التطبيقات في مستأجر Microsoft Entra.
  • تريد استخدام تسجيل تطبيق من مستأجر Microsoft Entra مختلف عن المستأجر الذي يوجد فيه تطبيقك.
  • لا يتوفر خيار إنشاء تسجيل جديد للسحب الحكومية.

إنشاء تسجيل تطبيق جديد واستخدامه أو استخدام تسجيل موجود تم إنشاؤه بشكل منفصل.

الخيار 1: إنشاء تسجيل تطبيق جديد واستخدامه

استخدم هذا الخيار ما لم تكن بحاجة إلى إنشاء تسجيل تطبيق بشكل منفصل. يمكنك تخصيص تسجيل التطبيق في Microsoft Entra بمجرد إنشائه.

إشعار

لا يتوفر خيار إنشاء تسجيل جديد تلقائيا للسحب الحكومية. بدلاً من ذلك، حدد تسجيلاً بشكل منفصل.

أدخل اسم تسجيل التطبيق الجديد.

حدد نوع الحساب المدعوم:

  • المستأجر الحالي - مستأجر واحد. الحسابات في هذا الدليل التنظيمي فقط. يمكن لجميع حسابات المستخدمين والضيوف في دليلك استخدام التطبيق أو API الخاص بك. استخدم هذا الخيار إذا كان جمهورك المستهدف داخليًا في مؤسستك.
  • أي دليل Microsoft Entra - متعدد المستأجرين. الحسابات في أي دليل تنظيمي. يمكن لجميع المستخدمين الذين لديهم حساب عمل أو مدرسة من Microsoft استخدام التطبيق أو واجهة برمجة التطبيقات. يتضمن ذلك المدارس والشركات التي تستخدم Office 365. استخدم هذا الخيار إذا كان جمهورك المستهدف هو العملاء التجاريين أو التعليميين ولتمكين تعدد الإيجارات.
  • أي دليل Microsoft Entra وحسابات Microsoft الشخصية. الحسابات في أي دليل تنظيمي وحسابات Microsoft الشخصية (على سبيل المثال، Skype وXbox). يمكن لجميع المستخدمين الذين لديهم حساب عمل أو مدرسة أو حساب Microsoft شخصي استخدام التطبيق أو واجهة برمجة التطبيقات. وهو يتضمن المدارس والشركات التي تستخدم Office 365 بالإضافة إلى الحسابات الشخصية المستخدمة لتسجيل الدخول إلى خدمات مثل Xbox وSkype. استخدم هذا الخيار لاستهداف أوسع مجموعة من هويات Microsoft ولتمكين تعدد المستأجرين.
  • حسابات Microsoft الشخصية فقط. الحسابات الشخصية المستخدمة لتسجيل الدخول إلى خدمات مثل Xbox وSkype. استخدم هذا الخيار لاستهداف أوسع مجموعة من هويات Microsoft.

يمكنك تغيير اسم التسجيل أو أنواع الحسابات المدعومة لاحقا إذا أردت ذلك.

يتم إنشاء سر العميل كإعداد تطبيق لزجة الفتحة يسمى MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. يمكنك تحديث هذا الإعداد لاحقا لاستخدام مراجع Key Vault إذا كنت ترغب في إدارة بيانات سرية في Azure Key Vault.

الخيار 2: قم باستخدام تسجيل موجود تم إنشاؤه بشكل منفصل

إما:

  • حدد اختيار تسجيل تطبيق موجود في هذا الدليل وحدد تسجيل تطبيق من القائمة المنسدلة.
  • حدد توفير تفاصيل تسجيل تطبيق موجود وقم بتوفير:
    • معرف التطبيق (العميل).
    • سر العميل (مستحسن). قيمة سرية يستخدمها التطبيق لإثبات هويته عند طلب رمز مميز. يتم حفظ هذه القيمة في تكوين التطبيق الخاص بك كإعداد تطبيق لزجة فتحة يسمى MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. إذا لم يتم تعيين سر العميل، فإن عمليات تسجيل الدخول من الخدمة تستخدم تدفق المنح الضمني OAuth 2.0، وهو غير مستحسن* .
    • عنوان URL المصدر، الذي يأخذ النموذج <authentication-endpoint>/<tenant-id>/v2.0. استبدل <authentication-endpoint> بقيمة نقطة نهاية المصادقة الخاصة ببيئة السحابة. على سبيل المثال، سيستخدم مستأجر القوى العاملة في Azure العمومي "https://login.microsoftonline.com"؛ كنقطة نهاية المصادقة الخاصة به.

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

أثناء عملية التسجيل، في قسم Redirect URIs ، حدد Web for platform واكتب <app-url>/.auth/login/aad/callback. على سبيل المثال، https://contoso.azurewebsites.net/.auth/login/aad/callback

بعد الإنشاء، قم بتعديل تسجيل التطبيق:

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

    بالنسبة لتطبيق مستأجر واحد، يُصبح بإمكانك استخدام القيمة الافتراضية، الموجودة في النموذج api://<application-client-id>. يمكنك أيضا تحديد URI أكثر قابلية للقراءة مثل https://contoso.com/api بناءً على أحد المجالات التي تم التحقق منها للمستأجر الخاص بك. بالنسبة لتطبيق متعدد المستأجرين، يجب توفير URI مخصص. لمعرفة المزيد حول التنسيقات المقبولة لعناوين URL لمعرف التطبيق، قم بمراجعةمرجع أفضل ممارسات تسجيلات التطبيق.

  2. حدد إضافة نطاق.

    1. فيما يتعلقباسم النطاق، قم بإدخالuser_impersonation.
    2. في روبوت Who يمكن الموافقة، حدد مسؤول والمستخدمين إذا كنت تريد السماح للمستخدمين بالموافقة على هذا النطاق.
    3. في مربعات النص، أدخل اسم نطاق الموافقة والوصف الذي تريد أن يراه المستخدمون على صفحة الموافقة. على سبيل المثال، أدخل < اسم > تطبيق Access.
    4. حدد إضافة نطاق.

  3. (مستحسن) لإنشاء سر عميل:

    1. من التنقل الأيسر، حدد Certificates and secrets>Client secrets>New client secret.
    2. أدخل وصفاً وانتهاء صلاحية وقم بتحديد إضافة.
    3. في حقل القيمة ، انسخ قيمة سر العميل. لن يتم عرضه مرة أخرى بمجرد التنقل بعيدا عن هذه الصفحة.

  4. (اختياري) لإضافة عناوين URL متعددة للرد، حدد المصادقة.

تكوين عمليات التحقق الإضافية

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

بالنسبة لمتطلبات تطبيق العميل، اختر ما إذا كنت تريد:

  • السماح بالطلبات فقط من هذا التطبيق نفسه
  • السماح بالطلبات من تطبيقات عميل معينة
  • السماح بالطلبات من أي تطبيق (غير مستحسن)

بالنسبة لمتطلبات الهوية، اختر ما إذا كنت تريد:

  • السماح بالطلبات من أي هوية
  • السماح بطلبات من هويات محددة

بالنسبة لمتطلبات المستأجر، اختر ما إذا كنت تريد:

  • السماح بالطلبات فقط من مستأجر المصدر
  • السماح بالطلبات من مستأجرين محددين
  • استخدام القيود الافتراضية استنادا إلى المصدر

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

تكوين إعدادات المصادقة

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

لتقييد الوصول، حدد ما إذا كنت تريد:

  • طلب المصادقة
  • السماح بالوصول غير المصادق عليه

للطلبات غير المصادق عليها

  • HTTP 302 Found redirect: مستحسن لمواقع الويب
  • HTTP 401 غير مصرح به: مستحسن لواجهات برمجة التطبيقات
  • HTTP 403 ممنوع
  • لم يتم العثور على HTTP 404

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

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

إذا حددت تكوين القوى العاملة، يمكنك تحديد Next: Permissions وإضافة أي أذونات Microsoft Graph يحتاجها التطبيق. تتم إضافة هذه إلى تسجيل التطبيق، ولكن يمكنك أيضًا إجراء تغيير عليها لاحقًا. إذا حددت التكوين الخارجي، يمكنك إضافة أذونات Microsoft Graph لاحقا.

حدد إضافة.

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

للحصول على مثال لتكوين تسجيل الدخول إلى Microsoft Entra لتطبيق ويب يصل إلى Azure Storage وMicrosoft Graph، راجع هذا البرنامج التعليمي.

تخويل الطلبات

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

يمكن لتطبيقك اتخاذ قرارات التخويل في التعليمات البرمجية. توفر App Service Authentication بعض عمليات التحقق المضمنة، والتي يمكن أن تساعد، ولكنها قد لا تكون كافية وحدها لتغطية احتياجات التخويل لتطبيقك.

تلميح

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

إجراء عمليات التحقق من الصحة من التعليمات البرمجية للتطبيق

عند إجراء عمليات التحقق من التخويل في التعليمات البرمجية للتطبيق، يمكنك استخدام معلومات المطالبات التي توفرها App Service Authentication. يحتوي العنوان الذي تم إدخاله x-ms-client-principal على كائن JSON بترميز Base64 مع المطالبات المؤكدة حول المتصل. بشكل افتراضي، تمر هذه المطالبات من خلال تعيين المطالبات، لذلك قد لا تتطابق أسماء المطالبات دائما مع ما قد تراه في الرمز المميز. على سبيل المثال، يتم تعيين المطالبة tid إلى http://schemas.microsoft.com/identity/claims/tenantid بدلا من ذلك.

يمكنك أيضا العمل مباشرة مع الرمز المميز للوصول الأساسي من العنوان الذي تم إدخاله x-ms-token-aad-access-token .

استخدام نهج تخويل مضمن

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

يوضح هذا القسم كيفية تمكين عمليات التحقق المضمنة باستخدام واجهة برمجة تطبيقات مصادقة App Service V2. حاليا، الطريقة الوحيدة لتكوين هذه الفحوصات المضمنة هي عبر قوالب Azure Resource Manager أو واجهة برمجة تطبيقات REST.

داخل كائن API، يحتوي تكوين موفر هوية Microsoft Entra على validation قسم يمكن أن يتضمن كائن defaultAuthorizationPolicy كما في البنية التالية:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
الخاصية ‏‏الوصف
defaultAuthorizationPolicy مجموعة من المتطلبات التي يجب تلبيتها من أجل الوصول إلى التطبيق. يتم منح الوصول استنادا إلى منطقية AND على كل من خصائصه المكونة. عندما allowedApplications يتم تكوين كل من و allowedPrincipals ، يجب أن يفي الطلب الوارد بكلا المتطلبين من أجل قبوله.
allowedApplications قائمة السماح لمعرفات عميل تطبيق السلسلة التي تمثل مورد العميل الذي يتصل بالتطبيق. عند تكوين هذه الخاصية كصفيف nonempty، سيتم قبول الرموز المميزة التي تم الحصول عليها بواسطة تطبيق محدد في القائمة فقط.

يقيم appid هذا النهج أو azp مطالبة الرمز المميز الوارد، والذي يجب أن يكون رمزا مميزا للوصول. راجع مرجع مطالبات النظام الأساسي للهويات في Microsoft.
allowedPrincipals تجميع عمليات التحقق التي تحدد ما إذا كان الأساسي الذي يمثله الطلب الوارد قد يصل إلى التطبيق. allowedPrincipals يستند رضا عن إلى منطقي OR على خصائصه المكونة.
identities (ضمن allowedPrincipals) قائمة السماح لمعرفات عناصر السلسلة التي تمثل المستخدمين أو التطبيقات التي لديها حق الوصول. عند تكوين هذه الخاصية كصفيف nonempty، allowedPrincipals يمكن استيفاء المتطلبات إذا تم تحديد المستخدم أو التطبيق الذي يمثله الطلب في القائمة. هناك حد إجمالي يبلغ 500 حرف عبر قائمة الهويات.

يقيم هذا النهج oid مطالبة الرمز المميز الوارد. راجع مرجع مطالبات النظام الأساسي للهويات في Microsoft.

بالإضافة إلى ذلك، يمكن تكوين بعض عمليات التحقق من خلال إعداد تطبيق، بغض النظر عن إصدار واجهة برمجة التطبيقات المستخدم. WEBSITE_AUTH_AAD_ALLOWED_TENANTS يمكن تكوين إعداد التطبيق بقائمة مفصولة بفواصل تصل إلى 10 معرفات مستأجر (على سبيل المثال، "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc") للمطالبة بأن يكون الرمز المميز الوارد من أحد المستأجرين المحددين، كما هو محدد في tid المطالبة. WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL يمكن تكوين إعداد التطبيق إلى "true" أو "1" لطلب الرمز المميز الوارد لتضمين oid مطالبة. يتم تجاهل هذا الإعداد والتعامل معه على أنه صحيح إذا allowedPrincipals.identities تم تكوينه (حيث يتم التحقق من المطالبة oid مقابل قائمة الهويات المتوفرة هذه).

يتم إعطاء الطلبات التي تفشل في عمليات التحقق المضمنة هذه استجابة HTTP 403 Forbidden .

تكوين تطبيقات العميل للوصول إلى خدمة التطبيقات

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

تطبيق العميل الأصلي

يمكنك تسجيل العملاء الأصليين لطلب الوصول إلى واجهات برمجة التطبيقات الخاصة بتطبيق App Service نيابة عن مستخدم مسجل الدخول.

  1. من قائمة المدخل، حدد Microsoft Entra.

  2. من جزء التنقل الأيسر، حدد تسجيلات>التطبيق تسجيل جديد.

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

  4. في Redirect URI، حدد Public client (mobile & desktop) واكتب عنوان URL <app-url>/.auth/login/aad/callback. على سبيل المثال، https://contoso.azurewebsites.net/.auth/login/aad/callback

  5. حدد تسجيل.

  6. بعد إنشاء تسجيل التطبيق، قم بنسخ قيمة معرف التطبيق (العميل).

    إشعار

    فيما يتعلق بتطبيق Microsoft Store، استخدم حزمة SID كعنوان URI بدلا من ذلك.

  7. من جزء التنقل الأيمن، حدد أذونات واجهة برمجة التطبيقات إضافة إذن>واجهات>برمجة التطبيقات الخاصة بي.

  8. حدد تسجيل التطبيق الذي أنشأته مسبقاً لتطبيق App Service. إذا لم تشاهد تسجيل التطبيق، فتأكد من إضافة نطاق user_impersonation في تسجيل التطبيق.

  9. ضمن الأذونات التفويضية، حدد user_impersonation، ثم حدد إضافة أذونات.

لقد قمت بتكوين تطبيق عميل أصلي يمكنه طلب الوصول إلى تطبيق App Service نيابة عن مستخدم.

التطبيق الخفي الخاص بالعميل (مكالمات خدمة إلى خدمة)

في بنية N-tier، يمكن لتطبيق العميل الحصول على رمز مميز للاتصال بتطبيق App Service أو Function نيابة عن تطبيق العميل نفسه (وليس نيابة عن مستخدم). هذا السيناريو مفيد للتطبيقات الخفية غير التفاعلية التي تؤدي مهام بدون مستخدم مسجّل الدخول. يستخدم هذا التطبيق منح بيانات اعتماد العميل OAuth 2.0.

  1. من قائمة المدخل، حدد Microsoft Entra.
  2. من جزء التنقل الأيسر، حدد تسجيلات>التطبيق تسجيل جديد.
  3. عندما تظهر صفحة تسجيل تطبيق، قم بإدخال اسم للتطبيق الخاص بك.
  4. فيما يتعلق بالتطبيق الخفي، لا تحتاج إلى عنوان URI لإعادة التوجيه حتى تتمكن من الاحتفاظ بذلك فارغا.
  5. حدد تسجيل.
  6. بعد إنشاء تسجيل التطبيق، قم بنسخ قيمة معرف التطبيق (العميل).
  7. من التنقل الأيسر، حدد Certificates and secrets>Client secrets>New client secret.
  8. أدخل وصفاً وانتهاء صلاحية وقم بتحديد إضافة.
  9. في حقل القيمة ، انسخ قيمة سر العميل. لن يتم عرضه مرة أخرى بمجرد التنقل بعيدا عن هذه الصفحة.

يمكنك الآن طلب الرمز المميز للوصول باستخدام معرف العميل وسر العميل عن طريق تعيين المعلمة resource إلى معرف التطبيق URI للتطبيق المستهدف. يمكن بعد ذلك تقديم رمز الوصول المميز الناتج إلى التطبيق الهدف باستخدام عنوان التخويل OAuth 2.0 القياسي، وستتحقق مصادقة App Service من صحة الرمز المميز وتستخدمه كالمعتاد للإشارة الآن إلى أن المتصل (تطبيق في هذه الحالة، وليس مستخدما) تمت مصادقته.

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

  1. قم بتحديد دور التطبيق في بيان التجميع لتسجيل التطبيق الذي يمثل تطبيق App Service أو Function الذي تريد حمايته.
  2. في تسجيل التطبيق الذي يمثل العميل الذي يحتاج إلى تخويل، حدد أذونات واجهة برمجة التطبيقات إضافة>إذن واجهات>برمجة التطبيقات الخاصة بي.
  3. قم بتحديد تسجيل التطبيق الذي أنشأته في وقت سابق. إذا لم تتمكن من رؤية تسجيل التطبيق، فتأكد من أنك قمت بإضافة دور التطبيق.
  4. ضمن أذونات التطبيق، قم بتحديد دور التطبيق الذي أنشأته سابقا، ثم حدد إضافة أذونات.
  5. تأكد من تحديد منح موافقة المسؤول من أجل تخويل تطبيق العميل لطلب الإذن.
  6. على غرار السيناريو السابق (قبل إضافة أي أدوار)، يمكنك الآن طلب الرمز المميز للوصول لنفس الهدف resource، ويتضمن roles الرمز المميز للوصول مطالبة تحتوي على أدوار التطبيق التي تم تخويله لتطبيق العميل.
  7. ضمن App Service الهدف أو التعليمات البرمجية لتطبيق الوظائف، يمكنك الآن التحقق من أن الأدوار المتوقعة موجودة في الرمز المميز (لا يتم تنفيذ ذلك بواسطة مصادقة App Service). لمزيد من المعلومات، قم بمراجعةالرموز المميزة للوصول.

لقد قمت الآن بتكوين تطبيق عميل خفي يُصبح بإمكانه الوصول إلى تطبيق App Service الخاص بك باستخدام الهوية الخاصة به.

أفضل الممارسات

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

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

الترحيل إلى Microsoft Graph

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

  1. قم بتحديث عنوان URL المصدر لتضمين اللاحقة "/v2.0" إذا لم تكن موجودة بالفعل.

  2. قم بإزالة طلبات أذونات Azure AD Graph من تكوين تسجيل الدخول. تعتمد الخصائص التي يجب تغييرها على إصدار واجهة برمجة تطبيقات الإدارة التي تستخدمها:

    • إذا كنت تستخدم V1 API (/authsettings)، فسيكون هذا في additionalLoginParams الصفيف.
    • إذا كنت تستخدم V2 API (/authsettingsV2)، فسيكون هذا في loginParameters الصفيف.

    ستحتاج إلى إزالة أي مرجع إلى "https://graph.windows.net"، على سبيل المثال. يتضمن هذا المعلمة resource (التي لا تدعمها نقطة النهاية "/v2.0") أو أي نطاقات تطلبها على وجه التحديد من Azure AD Graph.

    ستحتاج أيضا إلى تحديث التكوين لطلب أذونات Microsoft Graph الجديدة التي قمت بإعدادها لتسجيل التطبيق. يمكنك استخدام النطاق الافتراضي. لتبسيط هذا الإعداد في كثير من الحالات. للقيام بذلك، أضف معلمة scope=openid profile email https://graph.microsoft.com/.defaultتسجيل دخول جديدة .

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

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