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

  • مقالة
  • قراءة خلال 9 دقائق

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

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

ملاحظة

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

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

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

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

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

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

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

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

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

  5. (اختياري) انقر فوق التالي: الأذونات وإضافة أي نطاقات يحتاجها التطبيق. ستتم إضافتها إلى تسجيل التطبيق ، ولكن يمكنك أيضا تغييرها لاحقا.

  6. انقر فوق Add.

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

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

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

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

إنشاء تسجيل تطبيق في Azure AD لتطبيق خدمة التطبيقات

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

  • معرف العميل
  • معرف المستأجر
  • سر العميل (اختياري)
  • معرف التطبيق ID URI

لتسجيل التطبيق، نفذ الخطوات التالية:

  1. سجل الدخول إلى مدخل Azure، وابحث عن خدمات التطبيقات وحددها، ثم حدد تطبيقك. لاحظ عنوان URL لتطبيقك. ستستخدمه لتكوين تسجيل تطبيق Azure Active Directory.

  2. من قائمة البوابة الإلكترونية، حدد Azure Active Directory، ثم انتقل إلى علامة التبويب تسجيلات التطبيقات وحدد تسجيل جديد.

  3. في صفحة تسجيل طلب ، أدخل اسما لتسجيل تطبيقك.

  4. في إعادة توجيه URI، حدد ويب واكتب <app-url>/.auth/login/aad/callback. على سبيل المثال، ⁧https://contoso.azurewebsites.net/.auth/login/aad/callback⁩.

  5. اختر ⁧⁩تسجيل⁧⁩.

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

  7. تحديد المصادقة ضمن المنحة الضمنية والتدفقات المختلطة، قم بتمكين الرموز المميزة للمعرف للسماح ل OpenID الاتصال تسجيل دخول المستخدم من App Service. حدد ⁧⁩حفظ⁧⁩.

  8. (اختياري) حدد العلامة التجارية. في عنوان URL للصفحة الرئيسية، أدخل عنوان URL لتطبيق App Service وحدد حفظ.

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

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

    يتم حفظ القيمة تلقائيا.

  10. حدد ⁧⁩إضافة نطاق⁧⁩.

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

  11. (اختياري) لإنشاء سر عميل، حدد أسرار & الشهاداتأسرار>العميلسر>عميل جديد. أدخل وصفا وانتهاء الصلاحية وحدد إضافة. انسخ القيمة السرية للعميل الموضحة في الصفحة. لن يتم عرضه مرة أخرى.

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

تمكين Azure Active Directory في تطبيق "خدمة التطبيقات"

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

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

  3. حدد Microsoft في القائمة المنسدلة موفر الهوية.

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

    الحقل الوصف
    مُعرَّف التطبيق (العميل) استخدم معرف التطبيق (العميل) لتسجيل التطبيق .
    سر العميل استخدم سر العميل الذي أنشأته في تسجيل التطبيق. باستخدام سر العميل ، يتم استخدام التدفق المختلط وستعيد خدمة التطبيق الوصول وتحديث الرموز المميزة. عندما لا يتم تعيين سر العميل ، يتم استخدام التدفق الضمني ويتم إرجاع رمز معرف فقط. يتم إرسال هذه الرموز المميزة من قبل المزود وتخزينها في متجر الرموز المميزة EasyAuth.
    عنوان URL للجهة المصدرة استخدام <authentication-endpoint>/<tenant-id>/v2.0، واستبدال <نقطة> نهاية المصادقةبنقطة نهاية المصادقة لبيئة السحابة الخاصة بك (على سبيل المثال، "https://login.microsoftonline.com" ل Azure العمومي)، وكذلك استبدال <معرف> المستأجر بمعرف الدليل (المستأجر) الذي تم إنشاء تسجيل التطبيق فيه. يتم استخدام هذه القيمة لإعادة توجيه المستخدمين إلى مستأجر Azure AD الصحيح، بالإضافة إلى تنزيل بيانات التعريف المناسبة لتحديد مفاتيح توقيع الرمز المميز المناسبة وقيمة مطالبة مصدر الرمز المميز على سبيل المثال. بالنسبة للتطبيقات التي تستخدم Azure AD v1، احذف /v2.0 عنوان URL.
    جماهير الرمز المميز المسموح بها يعتبر معرف التطبيق (العميل) الذي تم تكوينه دائما ضمنيا جمهورا مسموحا به. إذا كان هذا تطبيقا سحابيا أو تطبيقا للخادم وتريد قبول الرموز المميزة للمصادقة من تطبيق خدمة تطبيقات العميل (يمكن استرداد الرمز المميز للمصادقة في رأس X-MS-TOKEN-AAD (دليل Azure النشط)-ID-TOKEN)، فأضف معرف التطبيق (العميل) لتطبيق العميل هنا.

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

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

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

  6. انقر فوق Add.

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

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

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

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

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

  1. في مدخل Azure، حدد تسجيلات>Active DirectoryAppتسجيل>جديد.

  2. في صفحة تسجيل طلب ، أدخل اسما لتسجيل تطبيقك.

  3. في إعادة توجيه URI، حدد عميل عام (سطح مكتب الجوال & ) واكتب عنوان URL <app-url>/.auth/login/aad/callback. على سبيل المثال، ⁧https://contoso.azurewebsites.net/.auth/login/aad/callback⁩.

    ملاحظة

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

  4. حدد Create.

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

  6. حدد ⁧⁩أذونات API⁧⁩⁧>⁩⁧⁩، وأضف إذن ⁧⁩⁧>⁩⁧⁩واجهات برمجة التطبيقات الخاصة بي⁧⁩.

  7. حدد تسجيل التطبيق الذي أنشأته سابقا لتطبيق App Service. إذا كنت لا ترى تسجيل التطبيق، فتأكد من إضافة نطاق user_impersonation في إنشاء تسجيل تطبيق في Azure AD لتطبيق App Service.

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

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

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

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

  1. في مدخل Azure، حدد تسجيلات>Active DirectoryAppتسجيل>جديد.
  2. في صفحة تسجيل طلب ، أدخل اسما لتسجيل تطبيقك الخفي.
  3. بالنسبة لتطبيق خفي ، لا تحتاج إلى عنوان URI لإعادة التوجيه حتى تتمكن من الاحتفاظ به فارغا.
  4. حدد Create.
  5. بعد إنشاء تسجيل التطبيق، انسخ قيمة معرف التطبيق (العميل).
  6. حدد أسرار الشهاداتسر &>عميل جديدإضافة.> انسخ القيمة السرية للعميل الموضحة في الصفحة. لن يتم عرضه مرة أخرى.

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

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

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

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

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

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

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

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