مشاركة عبر

تخصيص تسجيل الدخول والخروج في مصادقة خدمة تطبيقات Azure

  • مقالة

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

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

لا يوفر تكوين المدخل طريقة تشغيل لتقديم العديد من موفري تسجيل الدخول للمستخدمين (مثل Facebook وTwitter). ومع ذلك، ليس من الصعب إضافة الوظائف إلى تطبيقك. يتم توضيح الخطوات على النحو التالي:

أولًا، في صفحة المصادقة / التخويل في مدخل Microsoft Azure، قم بتكوين كل موفر هوية تريد تمكينه.

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

في صفحة تسجيل الدخول أو شريط التنقل أو أي موقع آخر من تطبيقك، أضف ارتباط تسجيل الدخول إلى كل موفر من الموفرين الذين قمت بتمكينهم (/.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/twitter">Log in with Twitter</a>
<a href="/.auth/login/apple">Log in with Apple</a>

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

لإعادة توجيه المستخدم بعد تسجيل الدخول إلى عنوان URL مخصص، استخدم معلمة سلسلة الاستعلام post_login_redirect_uri (لا يجب الخلط بينه وبين عنوان URI لإعادة التوجيه في تكوين موفر الهوية). على سبيل المثال، لتوجيه المستخدم إلى /Home/Index بعد تسجيل الدخول، استخدم التعليمات البرمجية HTML التالية:

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

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

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

للتحقق من صحة رمز الموفر المميز، يجب أولاً تكوين تطبيق الحاوية مع الموفر المطلوب. في وقت التشغيل، بعد استرداد رمز المصادقة المميز من الموفر الخاص بك، انشر الرمز المميز إلى /.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 اختيارية.
microsoftaccount {"access_token":"<access_token>"} أو {"authentication_token": "<token>" authentication_token مفضل على access_token. تُعد الخاصية expires_in اختيارية.
عند طلب الرمز المميز من خدمات Live، اطلب دائمًا النطاق wl.basic.
google {"id_token":"<id_token>"} تُعد الخاصية authorization_code اختيارية. سيؤدي توفير قيمة authorization_code إلى إضافة رمز وصول ورمز مميز للتحديث إلى مخزن الرمز المميز. عند التحديد، يمكن لـauthorization_code أيضًا أن تكون مصحوبة بخاصية redirect_uri اختياريًا.
facebook {"access_token":"<user_access_token>"} استخدم رمز وصول مستخدم صالحًا من Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

إشعار

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

إذا تم التحقق من صحة الرمز المميز للموفر بنجاح، فترجع واجهة برمجة التطبيقات مع authenticationToken في نص الاستجابة، وهو الرمز المميز لجلسة العمل.

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

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

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

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

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

  • مسح ملفات تعريف الارتباط الخاصة بالمصادقة من جلسة العمل الحالية.
  • حذف الرموز المميزة للمستخدم الحالي من مخزن الرمز المميز.
  • بالنسبة إلى 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

يوصى بترميز قيمة post_logout_redirect_uri.

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

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

شغِّل الأمر التالي في Azure Cloud Shell:

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

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

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

في مصادقة خدمة التطبيقات، يمكنك الاحتفاظ بأجزاء URL عبر تسجيل الدخول إلى OAuth. للقيام بذلك، قم بتعيين إعداد تطبيق يسمى WEBSITE_AUTH_PRESERVE_URL_FRAGMENT إلى true. يمكنك القيام بذلك في مدخل Microsoft Azure، أو ببساطة تشغيل الأمر التالي في Azure Cloud Shell:

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

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

يتيح لك كل من حساب Microsoft وMicrosoft Entra تسجيل الدخول من مجالات متعددة. على سبيل المثال، يسمح حساب Microsoft بحسابات outlook.com، live.com، وhotmail.com. يسمح Microsoft Entra بأي عدد من المجالات المخصصة لحسابات تسجيل الدخول. ومع ذلك، قد ترغب في تسريع المستخدمين مباشرة إلى صفحة تسجيل الدخول إلى Microsoft Entra ذات العلامة التجارية الخاصة بك (مثل contoso.com). لاقتراح اسم المجال لحسابات تسجيل الدخول، اتبع هذه الخطوات.

  1. في https://resources.azure.com الجزء العلوي من الصفحة، حدد Read/Write.

  2. في المستعرض الأيسر، انتقل إلى subscriptions><subscription-name>resourceGroups><resource-group-name>>providers>Microsoft.Web>sites><app-name>>config>authsettingsV2.

  3. انقر فوق تحرير.

  4. إضافة صفيف loginParameters مع domain_hint عنصر.

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

  5. انقر فوق وضع.

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

هام

من الممكن للعميل إزالة المعلمة domain_hint بعد تلقي عنوان URL لإعادة التوجيه، ثم تسجيل الدخول باستخدام مجال مختلف. لذلك، في حين أن هذه الوظيفة ملائمة، فإنها ليست ميزة أمان.

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

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

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

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

  1. انتقل إلى https://<app-name>.scm.azurewebsites.net/DebugConsole

  2. في مستكشف المستعرض لملفات App Service، انتقل إلى site/wwwroot. إذا لم يكن Web.config موجوداً، قم بإنشائه عن طريق تحديد +>ملف جديد.

  3. حدد القلم الرصاص لـWeb.config لتحريره. أضف رمز التكوين التالي وانقر فوق حفظ. إذا كان Web.config موجوداً بالفعل، فما عليك سوى إضافة <authorization> العنصر بكل شيء فيه. أضف الحسابات التي تريد السماح بها في <allow> العنصر.

    <?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>

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

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

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

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

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