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

مقالة
04/06/2022
قراءة خلال 6 دقائق

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

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

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

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

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

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</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 خاصة بالموفر. ثم يرسل رمز التطبيق الرمز المميز للمصادقة الناتجة إلى App Service للتحقق من صحته (راجع تدفق المصادقة) باستخدام طلب HTTP POST. تستخدم مجموعات تطوير البرامج (SDK) الخاصة بتطبيقات Azure للأجهزة المحمولة تدفق تسجيل الدخول هذا. لا يمنحك هذا التحقق من الصحة نفسه في الواقع إمكانية الوصول إلى موارد التطبيق المطلوبة ، ولكن التحقق الناجح سيمنحك رمزا مميزا للجلسة يمكنك استخدامه للوصول إلى موارد التطبيق.

للتحقق من صحة الرمز المميز للموفر، يجب أولا تكوين تطبيق 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` اختيارية.
`microsoftaccount`	`{"access_token":"<access_token>"}` أو `{"authentication_token": "<token>"`	`authentication_token` يفضل على `access_token`. الخاصية `expires_in` اختيارية. عند طلب الرمز المميز من الخدمات المباشرة ، اطلب `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":"<acces_token_secret>"}`

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

مسح ملفات تعريف ارتباط المصادقة من الجلسة الحالية.
حذف الرموز المميزة للمستخدم الحالي من متجر الرموز المميزة.
بالنسبة إلى Azure Active Directory وGoogle، يقوم بإجراء تسجيل خروج من جانب الخادم على موفر الهوية.

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

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

بشكل افتراضي، يؤدي تسجيل الخروج الناجح إلى إعادة توجيه العميل إلى عنوان URL /.auth/logout/done. يمكنك تغيير صفحة إعادة التوجيه بعد تسجيل الخروج بإضافة معلمة الاستعلام 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. يمكنك القيام بذلك في مدخل Azure، أو ببساطة تشغيل الأمر التالي في Azure Cloud Shell:

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

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

في https://resources.azure.com، في أعلى الصفحة، حدد قراءة/كتابة.
في المستعرض الأيمن، انتقل إلى الاشتراكاتالاشتراك-nameresourceGroupsresource-group-nameprovidersMicrosoft.Websitesapp-nameconfigauthsettingsV2>>><>>><>><>>>.
انقر فوق Edit.

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

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

انقر فوق وضع.

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

هام

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

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

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

مستوى الخادم
مستوى موفر الهوية
مستوى التطبيق

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

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

انتقل إلى https://<app-name>.scm.azurewebsites.net/DebugConsole
في مستكشف المستعرض الخاص بملفات App Service، انتقل إلى site/wwwroot. في حالة عدم وجود Web.config ، قم بإنشائه عن طريق تحديد +>ملف جديد.
حدد القلم الرصاص 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>
```

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

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

بالنسبة إلى Azure App Service، يمكنك إدارة الوصول على مستوى المؤسسة مباشرة في Azure AD. للحصول على التعليمات، راجع كيفية إزالة وصول مستخدم إلى تطبيق.
بالنسبة إلى Google، يمكن تهيئة مشاريع واجهة برمجة تطبيقات Google التي تنتمي إلى مؤسسة للسماح بالوصول إلى المستخدمين في مؤسستك فقط (راجع صفحة دعم إعداد OAuth 2.0 من Google).

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

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

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

هل هذه الصفحة مفيدة؟

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

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