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

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

• معرِّف Microsoft Entra
• Facebook
• Google
• موقع Twitter
• موفر OpenID Connect
• تسجيل الدخول باستخدام Apple (معاينة)

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

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

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

إشعار

لا يتوفر خيار إنشاء تسجيل جديد تلقائيا للسحب الحكومية أو عند استخدام [معرف Microsoft Entra للعملاء (معاينة)]. بدلاً من ذلك، حدد تسجيلاً بشكل منفصل.

اختيار 1: إنشاء تسجيل تطبيق جديد بشكل تلقائي

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

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

2. حددالمصادقة في القائمة على اليسار. انقر فوق إضافة مزود الهوية.

3. قم بتحديد Microsoft في القائمة المنسدلة لموفر الهوية. يتم تحديد الخيار الخاص بإنشاء تسجيل جديد بشكل افتراضي. يُصبح بإمكانك تغيير اسم التسجيل أو أنواع الحسابات المدعومة.

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

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

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

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

6. حدد إضافة.

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

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

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

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

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

الخطوة 1: إنشاء تسجيل تطبيق في معرف Microsoft Entra لتطبيق App Service

أثناء إنشاء تسجيل التطبيق، اجمع المعلومات التالية التي ستحتاج إليها لاحقا عند تكوين المصادقة في تطبيق App Service:

• معرف العميل
• معرف المستأجر
• سر العميل (اختياري، ولكن موصى به)
• عنوان URI لمُعرِّف التطبيق

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

لإجراء عملية تسجيل التطبيق، نفذ الخطوات التالية:

1. سجّل الدخول إلى مدخل Microsoft Azure، وابحث عن App Services وحددها، ثم حدد تطبيقك. لاحظ عنوان URL للتطبيق الخاص بك. ستستخدمه لتكوين تسجيل تطبيق Microsoft Entra.

2. انتقل إلى المستأجر الخاص بك في المدخل:

   مستأجر القوى العاملة

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

   مستأجر العميل

   1. إذا لم يكن لديك مستأجر عميل بالفعل، فقم بإنشاء مستأجر باتباع الإرشادات الواردة في إنشاء هوية العميل ومستأجر إدارة الوصول (CIAM).

   2. قم بتبديل الدليل الخاص بك في مدخل Microsoft Azure إلى مستأجر العميل.

      تلميح

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

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

3. في شاشة "Overview"، دون معرف المستأجر، بالإضافة إلى المجال الأساسي.

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

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

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

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

8. حدد تسجيل.

9. بعد إنشاء تسجيل التطبيق، قم بنسخمعرف التطبيق (العميل)ومعرف الدليل (المستأجر) في وقت لاحق.

10. من جزء التنقل الأيسر، حدد Authentication. ضمن المنح الضمنية والتدفقات الهجينة، فعّل الرموز المميزة للمعرف للسماح بعمليات تسجيل دخول مستخدم OpenID Connect من خلال App Service. حدد حفظ.

11. (اختياري) من جزء التنقل الأيمن، حدد Branding & properties. في عنوان URL للصفحة الرئيسية، أدخل عنوان URL لتطبيق App Service الخاص بك وحدد Save.

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

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

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

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

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

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

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

16. الانتهاء من إعداد تسجيل التطبيق الخاص بك:

    مستأجر القوى العاملة

    لا توجد خطوات أخرى مطلوبة لمستأجر القوى العاملة.

    مستأجر العميل

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

       1. انتقل مرة أخرى إلى المستأجر وحدد External identities.
       2. (اختياري) تكوين موفري الهوية ضمن جميع موفري الهوية. راجع أساليب المصادقة وموفري الهوية للعملاء للحصول على تفاصيل حول الخيارات المتاحة.
       3. حدد تدفق>المستخدم تدفق مستخدم جديد.
       4. أدخل اسما مثل "SignUpSignIn"، ثم حدد موفري الهوية وسمات المستخدم التي ترغب في استخدامها في هذا التدفق. عند الانتهاء، حدد Create.

       تتم تغطية هذه الخطوات أيضا في إنشاء تدفق مستخدم الاشتراك وتسجيل الدخول.

    2. تكوين تسجيل التطبيق للعمل مع تدفق المستخدم:

       1. حدد تدفق المستخدم الذي أنشأته للتو.
       2. حدد التطبيقات>إضافة تطبيق.
       3. ابحث عن تسجيل التطبيق الذي أنشأته سابقا، وحدده، ثم حدد تحديد.

       تتم تغطية هذه الخطوات أيضا في إضافة التطبيق الخاص بك إلى تدفق المستخدم.

    3. قم بتبديل الدليل مرة أخرى إلى المستأجر الذي يتضمن اشتراكك وApp Service بحيث يمكنك تنفيذ الخطوات التالية.

الخطوة 2: تمكين معرف Microsoft Entra في تطبيق App Service

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

2. من جزء التنقل الأيمن، حدد Authentication>Add identity provider>Microsoft.

3. حدد نوع المستأجر لتسجيل التطبيق الذي أنشأته.

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

   مستأجر القوى العاملة

   بالنسبة إلى نوع تسجيل التطبيق، اختر أحد الإجراءات التالية:

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

   يجب أن تكون نقطة نهاية المصادقة لمستأجر القوى العاملة قيمة خاصة ببيئة السحابة. على سبيل المثال، سيستخدم مستأجر القوى العاملة في Azure العمومي "https://login.microsoftonline.com"؛ كنقطة نهاية المصادقة الخاصة به. دون قيمة نقطة نهاية المصادقة، حيث إنها مطلوبة لإنشاء عنوان URL المناسب لمصدر الملفات.

   مستأجر العميل

   بالنسبة لمستأجر العميل، يجب عليك تعبئة قيم التكوين يدويا وفقا للجدول التالي.

   يجب أن تكون https://<tenant-subdomain>.ciamlogin.comنقطة نهاية المصادقة لمستأجر العميل ، مستبدلة <نطاق المستأجر الفرعي> بالمجال الفرعي الافتراضي للمستأجر. المجال الفرعي الافتراضي هو جزء من المجال الأساسي للمستأجر، والذي يجب أن يكون من النموذج <tenant-subdomain>.onmicrosoft.com وتم تعيينه أثناء إنشاء المستأجر. على سبيل المثال، إذا كان للمستأجر المجال "contoso.onmicrosoft.com"، فسيكون المجال الفرعي للمستأجر "contoso"، وستكون نقطة نهاية المصادقة "https://contoso.ciamlogin.com". دون قيمة نقطة نهاية المصادقة، حيث إنها مطلوبة لإنشاء عنوان URL المناسب لمصدر الملفات.

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

   الحقل	‏‏الوصف
   معرف التطبيق (العميل)	استخدم معرف التطبيق (العميل) من أجل تسجيل التطبيق.
   سر العميل	قم باستخدام سر العميل الذي أنشأته في تسجيل التطبيق. من خلال سر العميل، يُستخدم التدفق الهجين وسيعود تطبيق App Service للوصول وتحديث الرموز المميزة. عندما لا يتم تعيين سر العميل، يتم استخدام التدفق الضمني ويتم استعادة الرمز المميز للهوية فقط. يتم إرسال هذه الرموز المميزة من قبل الموفر وتخزينها في مخزن الرمز المميز لمصادقة App Service.
   عنوان URL المصدر	استخدم <authentication-endpoint>/<tenant-id>/v2.0، واستبدل <نقطة> نهاية المصادقة بنقطة نهاية المصادقة التي حددتها في الخطوة السابقة لنوع المستأجر وبيئة السحابة<، مع استبدال معرف> المستأجر بمعرف الدليل (المستأجر) الذي تم إنشاء تسجيل التطبيق فيه. بالنسبة للتطبيقات التي تستخدم Azure AD v1، قم بحذف /v2.0 عنوان URL. يتم استخدام هذه القيمة لإعادة توجيه المستخدمين إلى مستأجر Microsoft Entra الصحيح، وكذلك لتنزيل بيانات التعريف المناسبة لتحديد مفاتيح توقيع الرمز المميز المناسبة وقيمة مطالبة مصدر الرمز المميز على سبيل المثال. سيتم التعامل مع أي تكوين آخر غير نقطة نهاية خاصة للمستأجر على أنه متعدد المستأجرين. في التكوينات متعددة المستأجرين، لا يتم إجراء أي تحقق من صحة المصدر أو معرف المستأجر بواسطة النظام، ويجب التعامل مع هذه الفحوصات بالكامل في منطق تخويل التطبيق الخاص بك.
   الجمهور الخاصة بالرمز المميز المسموح به	هذا الحقل اختياري. يعتبر مُعرَّف التطبيق (العميل) الذي تم تكوينهدائماً ضمنياً ليكون جمهور مسموح به. إذا كان تطبيقك يمثل واجهة برمجة تطبيقات سيتم استدعاؤها من قبل عملاء آخرين، فيجب عليك أيضا إضافة معرف التطبيق URI الذي قمت بتكوينه في تسجيل التطبيق. هناك حد إجمالي يبلغ 500 حرف عبر قائمة الجماعات المستهدفة المسموح بها.

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

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

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

6. حدد إضافة.

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

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

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

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 في إنشاء تسجيل تطبيق في معرف Microsoft Entra لتطبيق App Service.

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

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

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

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

1. من قائمة المدخل، حدد Microsoft Entra ID.
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.

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

• نظرة عامة على مصادقة / تخويل App Service.
• البرنامج التعليمي: مصادقة المستخدمين وتخويلهم من طرف إلى طرف في Azure App Service

• البرنامج التعليمي: مصادقة المستخدمين وتخويلهم في تطبيق ويب يصل إلى Azure Storage وMicrosoft Graph
• البرنامج التعليمي: مصادقة المستخدمين وتخويلهم من طرف إلى طرف في Azure App Service