تخصيص عمليات تسجيل الدخول وتسجيل الخروج في مصادقة Azure App Service

توضح هذه المقالة كيفية تخصيص عمليات تسجيل دخول المستخدم وتسجيل الخروج أثناء استخدام المصادقة #B0 المضمنة والتخويل في Azure App Service #A1 .

استخدام موفري تسجيل الدخول المتعددين

لا يوفر تكوين مدخل Azure طريقة تسليم المفتاح لتقديم العديد من موفري تسجيل الدخول للمستخدمين. على سبيل المثال، قد ترغب في تقديم كل من Facebook وX كخيارات. لإضافة العديد من موفري تسجيل الدخول إلى تطبيقك:

1. في مدخل Microsoft Azure، في تطبيق الويب الخاص بك، حدد Settings>Authentication.

2. بالنسبة لإعدادات المصادقة، حدد تحرير.

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

4. في صفحة تسجيل الدخول أو شريط التنقل أو أي موقع آخر في تطبيقك، أضف ارتباط تسجيل الدخول إلى كل موفر من الموفرين الذين قمت بتمكينهم (/.auth/login/<provider>). على سبيل المثال:

   <a href="/.auth/login/aad">Log in with Microsoft Entra</a>
   <a href="/.auth/login/facebook">Log in with Facebook</a>
   <a href="/.auth/login/google">Log in with Google</a>
   <a href="/.auth/login/x">Log in with X</a>
   <a href="/.auth/login/apple">Log in with Apple</a>
   

عندما يحدد المستخدم أحد الارتباطات، تفتح الصفحة المعنية لتسجيل الدخول.

لإعادة توجيه المستخدم إلى عنوان URL مخصص بعد تسجيل الدخول، استخدم معلمة سلسلة الاستعلام #D0. على سبيل المثال، لنقل المستخدم إلى /Home/Index بعد تسجيل الدخول، استخدم رمز HTML التالي:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

إشعار

لا تخلط بين هذه القيمة وURI إعادة التوجيه في تكوين موفر الهوية.

#D0 استخدام تسجيل الدخول الموجه من قبل العميل

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

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

POST https://<appname>.azurewebsites.net/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

يختلف تنسيق الرمز المميز قليلا وفقا للموفر:

قيمة الموفر	مطلوب في نص الطلب	التعليقات
aad	{"access_token":"<access_token>"}	خصائص id_token وrefresh_token وexpires_in اختيارية.
google	{"id_token":"<id_token>"}	تُعد الخاصية authorization_code اختيارية. يوفر قيمة authorization_code إضافة رمز مميز للوصول ورمز تحديث مميز إلى مخزن الرمز المميز. عند تحديد #B0 ، يمكنك إرفاقه اختياريا بخاصية #D1.
facebook	{"access_token":"<user_access_token>"}	استخدم رمز وصول مستخدم صالحًا من Facebook.
twitter	{"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

إشعار

لا يدعم موفر GitHub لمصادقة App Service تسجيل الدخول والخروج المخصص.

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

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

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

GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

تسجيل الخروج من جلسة عمل

يمكن للمستخدمين بدء تسجيل الخروج عن طريق إرسال طلب GET إلى نقطة نهاية التطبيق /.auth/logout. طلب #D0:

• مسح ملفات تعريف الارتباط الخاصة بالمصادقة من جلسة العمل الحالية.
• حذف الرموز المميزة للمستخدم الحالي من مخزن الرمز المميز.
• يقوم بتسجيل الخروج من جانب الخادم على موفر الهوية ل Microsoft Entra وGoogle.

فيما يلي ارتباط بسيط لتسجيل الخروج على صفحة ويب:

<a href="/.auth/logout">Sign out</a>

بشكل افتراضي، يقوم تسجيل الخروج الناجح بإعادة توجيه العميل إلى عنوان URL /.auth/logout/complete. يمكنك تغيير صفحة إعادة توجيه ما بعد تسجيل الخروج عن طريق إضافة معلمة الاستعلام post_logout_redirect_uri. على سبيل المثال:

GET /.auth/logout?post_logout_redirect_uri=/index.html

نوصي #B0 ترميز #C1 قيمة #B2 .

عند استخدام عناوين URL المؤهلة بالكامل، يجب استضافة عنوان URL في نفس المجال أو تكوينه ك URL إعادة توجيه خارجي مسموح به لتطبيقك. يعيد المثال التالي التوجيه إلى عنوان URL #D0 غير مستضاف في نفس المجال:

GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com

قم بتشغيل الأمر التالي في #B0 Azure Cloud Shell #A1 :

az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls "https://myexternalurl.com"

الاحتفاظ بأجزاء محدد موقع المعلومات URL

بعد تسجيل دخول المستخدمين إلى تطبيقك، عادة ما يرغبون في إعادة توجيههم إلى نفس القسم من الصفحة نفسها، مثل /wiki/Main_Page#SectionZ. ومع ذلك، نظرا لأنه لا يتم إرسال أجزاء عنوان URL #B0 #C1 (على سبيل المثال، #B2 ) إلى الخادم، فلا يتم الاحتفاظ بها بشكل افتراضي بعد انتهاء تسجيل الدخول إلى OAuth وإعادة توجيهها مرة أخرى إلى تطبيقك. ثم يحصل المستخدمون على تجربة دون المستوى الأمثل عندما يحتاجون إلى الانتقال إلى نقطة الارتساء المطلوبة مرة أخرى. ينطبق هذا القيد على كافة حلول المصادقة من جانب الخادم.

في مصادقة App Service، يمكنك الاحتفاظ بأجزاء عنوان URL عبر تسجيل الدخول إلى OAuth عن طريق تعيين #D0 إلى #B1 . يمكنك استخدام إعداد التطبيق هذا في مدخل #B0 Azure #A1 ، أو يمكنك تشغيل الأمر التالي في #B2 Cloud Shell #A3 :

az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"

تعيين تلميح المجال لحسابات تسجيل الدخول

يسمح كل من حسابات Microsoft وMicrosoft Entra للمستخدمين بتسجيل الدخول من مجالات متعددة. على سبيل المثال، يسمح حساب Microsoft #B0 وحسابات #B1 #D2. يسمح Microsoft Entra بأي عدد من المجالات المخصصة لحسابات تسجيل الدخول. ومع ذلك، قد ترغب في تسريع المستخدمين مباشرة إلى صفحة تسجيل الدخول إلى Microsoft Entra ذات العلامة التجارية الخاصة بك (مثل #B0 ).

لاقتراح اسم المجال لحسابات تسجيل الدخول، اتبع الخطوات التالية:

1. في #B0 Resource Explorer #A1 ، في أعلى الصفحة، حدد #B2 Read/Write #A3 .

2. في الجزء الأيمن، انتقل إلى اشتراكات #B0 #A1 #A2 #A3 اسم الاشتراك #A4 #A5 #A6 resourceGroups #A7 #A8 #A9 موفري #A10 #A11 #A12 اسم مجموعة الموارد #A13 #A14 #A15 مواقع Microsoft.Web #A16 #A17 #A18 #A19 #A20 #A21 اسم التطبيق #A22 #A23 #A24 تكوين #A25 #A26 #A27 authsettingsV2 #A28 .

3. حدد تحرير.

4. إضافة صفيف #D0 بعنصر #D1:

   "identityProviders": {
       "azureActiveDirectory": {
           "login": {
               "loginParameters": ["domain_hint=<domain-name>"],
           }
       }
   }
   

5. حدد #B0 وضع #A1 .

يقوم هذا الإعداد بإلحاق معلمة سلسلة الاستعلام #D0 بعنوان URL لإعادة توجيه تسجيل الدخول.

هام

من الممكن للعميل إزالة المعلمة #D0 بعد تلقي عنوان URL لإعادة التوجيه، ثم تسجيل الدخول باستخدام مجال مختلف. لذلك على الرغم من أن هذه الدالة ملائمة، إلا أنها ليست ميزة أمان.

تخويل المستخدمين أو رفضهم

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

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

مستوى الخادم (تطبيقات Windows فقط)

بالنسبة لأي تطبيق Windows، يمكنك تعريف سلوك التخويل لخادم ويب IIS عن طريق تحرير ملف #D0. لا تستخدم تطبيقات Linux IIS ولا يمكن تكوينها من خلال #B0 .

1. للانتقال إلى وحدة تحكم تصحيح Kudu لتطبيقك، حدد أدوات> التطويرأدوات متقدمة وحدد Go. ثم حدد وحدة تحكم تتبع الأخطاء.

   يمكنك أيضا فتح هذه الصفحة باستخدام عنوان URL هذا: https://<app-name>-<random-hash>.scm.<region>.azurewebsites.net/DebugConsole. للحصول على قيم التجزئة والمنطقة العشوائية، في نظرة عامة على التطبيق، انسخ المجال الافتراضي.

2. في مستكشف المستعرض لملفات App Service، انتقل إلى #B0 . إذا لم يكن #D0 موجودا، فبادر بإنشائه عن طريق تحديد #B1 #A2 #A3 ملف جديد #A4 .

3. حدد القلم الرصاص #D0 لتحرير الملف. أضف رمز التكوين التالي، ثم حدد #B0 Save #A1 . إذا كان #D0 موجودا بالفعل، فما عليك سوى إضافة عنصر #D1 مع كل شيء فيه. في عنصر #D0، أضف الحسابات التي تريد السماح بها.

   <?xml version="1.0" encoding="utf-8"?>
   <configuration>
      <system.web>
         <authorization>
           <allow users="user1@contoso.com,user2@contoso.com"/>
           <deny users="*"/>
         </authorization>
      </system.web>
   </configuration>
   

مستوى موفر الهوية

قد يوفر موفر الهوية تخويلا معينا لتحويل المفتاح. على سبيل المثال:

• بالنسبة إلى Microsoft Entra، يمكنك إدارة الوصول على مستوى المؤسسة مباشرة. لمزيد من المعلومات، راجع إزالة وصول المستخدم إلى التطبيقات.
• بالنسبة إلى #B0 Google #A1 ، يمكن تكوين مشاريع واجهة برمجة تطبيقات Google التي تنتمي إلى مؤسسة #B2 #C3 للسماح بالوصول فقط إلى المستخدمين في مؤسستك. لمزيد من المعلومات، راجع إدارة عملاء OAuth.

مستوى التطبيق

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

المحتويات ذات الصلة

• #B0 البرنامج التعليمي: مصادقة المستخدمين وتخويلهم من طرف إلى طرف في Azure App Service #C1
• متغيرات البيئة وإعدادات التطبيق للمصادقة