المصادقة والتخويل في Azure App Service و Azure Functions

  • مقالة

توفر خدمة Azure App Service قدرات مصادقة وتخويل مضمنة (يشار إليها أحيانا باسم "Easy Auth")، بحيث يمكنك تسجيل الدخول للمستخدمين والوصول إلى البيانات عن طريق كتابة الحد الأدنى من التعليمات البرمجية أو عدم كتابتها في تطبيق الويب الخاص بك، وواجهة برمجة التطبيقات RESTful، والنهاية الخلفية للجوال، وكذلك Azure Functions. توضح هذه المقالة كيفية مساعدة App Service في تبسيط المصادقة والتخويل لتطبيقك.

لماذا تستخدم المصادقة المضمنة؟

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

قد يتطلب تنفيذ حل آمن للمصادقة (مستخدمو تسجيل الدخول) والتخويل (توفير الوصول إلى بيانات آمنة) جهداً كبيراً. يجب عليك التأكد من اتباع أفضل الممارسات والمعايير في الصناعة، والحفاظ على تنفيذك محدثًا. يمكن أن توفر لك ميزة المصادقة المضمنة لـ App Service وAzure Functions الوقت والجهد من خلال توفير مصادقة خارج الصندوق مع موفري هوية جهة الاتصال الخارجية، مما يسمح لك بالتركيز على بقية التطبيق الخاص بك.

  • تسمح لك خدمة Azure App Service بتكامل مجموعة متنوعة من إمكانات المصادقة في تطبيق الويب أو واجهة برمجة التطبيقات الخاصة بك دون تنفيذها بنفسك.
  • إنها بنيت مباشرة في النظام الأساسي ولا تتطلب أي لغة معينة، أو SDK، أو خبرة أمان أو حتى أي تعليمات برمجية للاستفادة.
  • يمكنك التكامل مع موفري تسجيل الدخول المتعددين. على سبيل المثال، Microsoft Entra وFacebook وGoogle وTwitter.

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

موفرو الهوية

تستخدم خدمة App Service هوية جهة الاتصال الخارجية، حيث يقوم موفر هوية تابع لجهة خارجية بإدارة هويات المستخدم وتدفق المصادقة لك. يتوفر موفري الهوية التالية بشكل افتراضي:

الموفر نقطة نهاية تسجيل الدخول إرشادات المساعدة
النظام الأساسي للهويات في Microsoft /.auth/login/aad تسجيل الدخول النظام الأساسي للهويات في Microsoft App Service
Facebook /.auth/login/facebook تسجيل الدخول إلى App Service Facebook
Google /.auth/login/google تسجيل الدخول إلى Google لخدمة التطبيقات
موقع Twitter /.auth/login/twitter تسجيل الدخول إلى App Service Twitter
GitHub /.auth/login/github تسجيل الدخول إلى App Service GitHub
تسجيل الدخول باستخدام Apple /.auth/login/apple تسجيل الدخول إلى App Service باستخدام تسجيل الدخول إلى Apple (معاينة)
أي موفر OpenID Connect /.auth/login/<providerName> تسجيل الدخول إلى App Service OpenID Connect

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

اعتبارات استخدام المصادقة المضمنة

سيؤدي تمكين هذه الميزة إلى إعادة توجيه جميع الطلبات إلى التطبيق الخاص بك تلقائيًا إلى HTTPS، بغض النظر عن إعداد تكوين App Service لفرض HTTPS. يمكنك تعطيل هذا مع الإعداد requireHttps في تكوين V2. ومع ذلك، نوصي بالالتزام بـ HTTPS، ويجب عليك التأكد من عدم إرسال أي رموز أمان عبر اتصالات HTTP غير الآمنة.

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

هام

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

كيف تعمل هذه الميزة

بنية الميزات

تدفق المصادقة

سلوك التخويل

مخزن الرمز المميز

التسجيل والتتبع

هيكل الميزة

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

تصميم يوضح الطلبات التي يتم اعتراضها من خلال عملية في وضع بيئة الاختبار المعزولة للموقع والتي تتفاعل مع موفري الهوية قبل السماح بالحركة إلى الموقع المنشور

يعالج البرنامج الوسيط للنظام الأساسي العديد من الأشياء لتطبيقك:

  • مصادقة المستخدمين والعملاء مع موفر (موفري) الهوية المحددين
  • التحقق من صحة وتخزين وتحديث رموز OAuth المميزة الصادرة عن موفر (موفري) الهوية المكونة
  • إدارة الجلسة المصدق عليها
  • إدخال معلومات الهوية في عناوين طلبات HTTP

تعمل الوحدة بشكل منفصل عن التعليمات البرمجية للتطبيق الخاص بك ويمكن تكوينها باستخدام إعدادات Azure Resource Manager أو باستخدام ملف تكوين. لا يلزم وجود أدوات SDK أو لغات كمبيوتر محددة أو تغييرات في تعليمة التطبيق الخاص بك.

بنية الميزات على Windows (توزيع غير متعلق بالحاوية)

تعمل الوحدة النمطية للمصادقة والتخويل كوحدة IIS أصلية في نفس بيئة الاختبار المعزولة للتطبيق الخاص بك. عند تمكينه، يمر كل طلب HTTP وارد من خلاله قبل معالجته بواسطة تعليمة تطبيقك.

بنية الميزات على Linux والحاويات

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

تدفق المصادقة

تدفق المصادقة هو نفسه لكافة موفري الخدمة ولكن يختلف استناداً إلى ما إذا كنت تريد تسجيل الدخول مع SDK لموفر الخدمة:

  • بدون SDK لموفر الخدمة: يفوض التطبيق تسجيل دخول جهة الاتصال الخارجية إلى App Service. وهذا هو الحال عادة مع تطبيقات المستعرض، والتي يمكن أن تقدم صفحة تسجيل دخول موفر الخدمة للمستخدم. يدير رمز الخادم عملية تسجيل الدخول، ولذلك يطلق عليه أيضاً التدفق الموجه من الخادم أو تدفق الخادم. تنطبق هذه الحالة على تطبيقات المستعرض وتطبيقات الأجهزة المحمولة التي تستخدم مستعرضا مضمنا للمصادقة.
  • مع SDK لموفر الخدمة: يقوم التطبيق بتسجيل دخول المستخدمين إلى موفر الخدمة يدوياً ثم يقوم بإرسال رمز المصادقة المميز إلى App Service للتحقق من الصحة. وهذا هو الحال عادة مع تطبيقات بلا مستعرض، والتي لا يمكن أن تقدم صفحة تسجيل دخول موفر الخدمة للمستخدم. يدير رمز التطبيق عملية تسجيل الدخول، ولذلك يطلق عليه أيضاً التدفق الموجه من العميل أو تدفق العميل. تنطبق هذه الحالة على واجهات برمجة تطبيقات REST وAzure Functions وعملاء مستعرض JavaScript، بالإضافة إلى تطبيقات المستعرض التي تحتاج إلى مزيد من المرونة في عملية تسجيل الدخول. كما ينطبق أيضًا على تطبيقات الأجهزة المحمولة الأصلية التي تسجل دخول المستخدمين باستخدام SDK الخاص بالموفر.

يمكن مصادقة الاستدعاءات من تطبيق مستعرض موثوق به في خدمة التطبيقات إلى REST API آخر في App Service أو Azure Functions باستخدام التدفق الموجه من الخادم. لمزيد من المعلومات، راجع تخصيص عمليات تسجيل الدخول وتسجيل الخروج.

يوضح الجدول أدناه خطوات تدفق المصادقة.

الخطوة بدون SDK لموفر الخدمة مع SDK لموفر الخدمة
1. تسجيل دخول المستخدم إعادة توجيه العميل إلى /.auth/login/<provider>. يقوم رمز العميل بتسجيل دخول المستخدم مباشرةً مع SDK لموفر الخدمة ويتلقى رمز مصادقة. لمزيد من المعلومات، راجع وثائق موفر الخدمة.
2. ما بعد المصادقة يقوم موفر الخدمة بإعادة توجيه العميل إلى /.auth/login/<provider>/callback. ينشر رمز العميل الرمز المميز من موفر الخدمة إلى /.auth/login/<provider> للتحقق من الصحة.
3. تأسيس جلسة عمل مصدق عليها تضيف App Service ملف تعريف ارتباط مصدق عليه للاستجابة. تقوم App Service بإرجاع رمز المصادقة المميز الخاص بها إلى رمز العميل.
4. خدمة المحتوى المصدق عليه يتضمن العميل ملف تعريف ارتباط المصادقة في الطلبات اللاحقة (يتم التعامل معه تلقائياً بواسطة المستعرض). رمز العميل يقدم رمز التخويل المميز في العنوان X-ZUMO-AUTH.

بالنسبة لمستعرضات العملاء، يمكن لخدمة App Service توجيه جميع المستخدمين غير المصدق عليهم تلقائياً إلى /.auth/login/<provider>. يمكنك أيضاً تقديم رابط /.auth/login/<provider> واحد أو أكثر للمستخدمين لتسجيل الدخول إلى تطبيقك باستخدام موفر الخدمة الذي يختارونه.

سلوك التخويل

هام

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

في مدخل Microsoft Azure، يمكنك تكوين App Service بعدد من السلوكيات عندما لا تتم مصادقة طلب وارد. تصف العناوين التالية الخيارات.

الوصول إلى إعادة الثبات

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

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

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

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

    تنبيه

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

    إشعار

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

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

  • HTTP 302 تم العثور على إعادة التوجيه: يوصى به لمواقع الويب إعادة توجيه الإجراء إلى أحد موفري الهوية المكونين. في هذه الحالات، يتم إعادة توجيه عميل مستعرض إلى /.auth/login/<provider> لموفر الخدمة الذي تختاره.
  • HTTP 401 غير مصرح به: يوصى به لواجهات برمجة التطبيقات إذا كان الطلب المجهول يأتي من تطبيق الأجهزة المحمولة الأصلي، فإن الاستجابة التي تم إرجاعها هي HTTP 401 Unauthorized. يمكنك أيضا تكوين الرفض ليكون HTTP 401 Unauthorized لجميع الطلبات.
  • HTTP 403 ممنوع تكوين الرفض ليكون HTTP 403 Forbidden لجميع الطلبات.
  • لم يتم العثور على HTTP 404 تكوين الرفض ليكون لكافة HTTP 404 Not found الطلبات.

مخزن الرمز المميز

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

  • نشر إلى المخطط الزمني للمستخدم المصادق عليه على Facebook
  • قراءة بيانات الشركة للمستخدم باستخدام واجهة برمجة تطبيقات Microsoft Graph

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

يتم تخزين الرموز المميزة للمعرف ورمز الوصول ورمز التحديث المميز مؤقتًا لجلسة العمل المصادق عليها، ولا يمكن الوصول إليها إلا من قبل المستخدم المقترن.

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

التسجيل والتتبع.

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

الاعتبارات عند استخدام Azure Front Door

عند استخدام Azure App Service مع Easy Auth خلف Azure Front Door أو وكلاء عكسيين آخرين، يجب مراعاة بعض الأشياء الإضافية.

  1. تعطيل التخزين المؤقت لسير عمل المصادقة

    راجع تعطيل ذاكرة التخزين المؤقت لسير عمل المصادقة لمعرفة المزيد حول كيفية تكوين القواعد في Azure Front Door لتعطيل التخزين المؤقت للصفحات المتعلقة بالمصادقة والتخويل.

  2. استخدام نقطة نهاية Front Door لإعادة التوجيه

    لا يمكن الوصول إلى App Service عادة مباشرة عند كشفها عبر Azure Front Door. يمكن منع ذلك، على سبيل المثال، عن طريق الكشف عن App Service عبر Private Link في Azure Front Door Premium. لمنع سير عمل المصادقة من إعادة توجيه حركة المرور مرة أخرى إلى App Service مباشرة، من المهم تكوين التطبيق لإعادة التوجيه مرة أخرى إلى https://<front-door-endpoint>/.auth/login/<provider>/callback.

  3. تأكد من أن App Service تستخدم عنوان URI الصحيح لإعادة التوجيه

    في بعض التكوينات، تستخدم App Service FQDN لخدمة التطبيقات ك URI لإعادة التوجيه بدلا من Front Door FQDN. سيؤدي هذا إلى مشكلة عند إعادة توجيه العميل إلى App Service بدلا من Front Door. لتغيير ذلك، forwardProxy يجب تعيين الإعداد لجعل Standard App Service تحترم X-Forwarded-Host العنوان الذي تم تعيينه بواسطة Azure Front Door.

    قد يستخدم وكلاء عكسيون آخرون مثل Azure Application Gateway أو منتجات الجهات الخارجية عناوين مختلفة ويحتاجون إلى إعداد forwardProxy مختلف.

    لا يمكن إجراء هذا التكوين عبر مدخل Microsoft Azure اليوم ويجب القيام به عبر az rest:

    تصدير الإعدادات

    az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

    تحديث الإعدادات

    ابحث عن

    "httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

    وتأكد من convention تعيين إلى Standard احترام X-Forwarded-Host العنوان المستخدم من قبل Azure Front Door.

    إعدادات الاستيراد

    az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

المزيد من الموارد

النماذج: