تكوين سلوك جلسة العمل في Azure Active Directory B2C

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

هل لديك ملاحظات إضافية؟

سيتم إرسال الملاحظات إلى Microsoft: بالضغط على الزر «إرسال»، سيتم استخدام ملاحظاتك لتحسين منتجات Microsoft وخدماتها. نهج الخصوصية.

قبل أن تبدأ، استخدم المنتقي Choose a policy type لاختيار نوع السياسة التي تقوم بإعدادها. يوفر Azure Active Directory B2C طريقتين لتحديد كيفية تفاعل المستخدمين مع تطبيقاتك: من خلال تدفقات محددة مسبقا للمستخدمين أو من خلال سياسات مخصصة قابلة للتكوين بشكل كامل. تختلف الخطوات المطلوبة في هذه المقالة لكل أسلوب.

يضيف تسجيل الدخول الأحادي (SSO) الأمان والراحة عند قيام المستخدمين بتسجيل الدخول عبر التطبيقات في Azure Active Directory B2C (Microsoft Azure Active Directory B2C). توضح هذه المقالة أساليب تسجيل الدخول الأحادية المستخدمة في Microsoft Azure Active Directory B2C وتساعدك على اختيار أسلوب تسجيل الدخول الأحادي "SSO" الأنسب عند تكوين النهج الخاص بك.

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

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

المتطلبات الأساسية

• إنشاء تدفق مستخدم لتمكين المستخدمين من تسجيل الدخول إلى تطبيقك.
• تسجيل تطبيق ويب.

• أكمل الخطوات في ابدأ العمل مع النهج المخصص في خدمات مجال Active Directory B2C
• تسجيل تطبيق ويب.

نظرة عامة على جلسة عمل Microsoft Azure Active Directory B2C

يتضمن التكامل مع Microsoft Azure Active Directory B2C ثلاثة أنواع من جلسات عمل تسجيل الدخول الأحادي "SSO":

• Azure AD B2C - جلسة تدار بواسطة Microsoft Azure Active Directory B2C
• موفر الهوية الموحدة - جلسة عمل يديرها موفر الهوية، على سبيل المثال حساب فيسبوك أو Salesforce أو حساب Microsoft
• التطبيق - جلسة يديرها تطبيق الويب أو الهاتف المحمول أو تطبيق صفحة واحدة

جلسة Microsoft Azure Active Directory B2C

عندما يقوم المستخدم بالمصادقة بنجاح باستخدام حساب محلي أو اجتماعي، يقوم Microsoft Azure Active Directory B2C بتخزين جلسة تستند إلى ملف تعريف الارتباط على متصفح المستخدم. ويتم تخزين ملف تعريف الارتباط تحت اسم المجال لمستأجر Microsoft Azure Active Directory B2C، مثل https://contoso.b2clogin.com.

إذا قام المستخدم بتسجيل الدخول مبدئياً باستخدام حساب موحد، ثم قام خلال نافذة وقت الجلسة (مدة البقاء، أو TTL) بتسجيل الدخول إلى التطبيق نفسه أو إلى تطبيق مختلف، فعندئذٍ يحاول Microsoft Azure Active Directory B2C الحصول على رمز مميز جديد للوصول من موفر الهوية الموحدة. وإذا انتهت مدة صلاحية جلسة عمل موفر الهوية الموحدة أو أصبحت غير صالحة، يطالب موفر الهوية الموحدة المستخدم ببيانات الاعتماد الخاصة به. أما إذا كانت جلسة العمل لا تزال نشطة (أو إذا قام المستخدم بتسجيل الدخول باستخدام حساب محلي بدلاً من حساب موحد)، فإن Microsoft Azure Active Directory B2C يأذن للمستخدم ويزيل المطالبات الإضافية.

كما يمكنك تكوين سلوك جلسة العمل، بما في ذلك TTL لجلسة العمل وكيفية مشاركة Microsoft Azure Active Directory B2C لجلسة العمل عبر النُهج والتطبيقات.

جلسة موفر الهوية الموحدة

يدير موفر الهوية الاجتماعية أو المؤسسية جلسة العمل الخاصة به. ويتم تخزين ملف تعريف الارتباط تحت اسم مجال موفر الهوية، مثل https://login.salesforce.com. كما لا يتحكم Microsoft Azure Active Directory B2C في جلسة موفر الهوية الموحدة. وبدلاً من ذلك، يتم تحديد سلوك جلسة العمل بواسطة موفر الهوية الموحدة.

ضع في اعتبارك السيناريو التالي:

1. يسجل أحد المستخدمين الدخول إلى فيسبوك للتحقق من الموجز الخاص به.
2. وفي وقت لاحق، يفتح المستخدم التطبيق الخاص بك ويبدأ عملية تسجيل الدخول. يعيد التطبيق توجيه المستخدم إلى Microsoft Azure Active Directory B2C لإكمال عملية تسجيل الدخول.
3. وفي صفحة الاشتراك أو تسجيل الدخول في Microsoft Azure Active Directory B2C، يختار المستخدم تسجيل الدخول باستخدام حسابه على فيسبوك. تتم إعادة توجيه المستخدم إلى فيسبوك. فإذا كان هناك جلسة عمل نشطة في فيسبوك، فلا تتم مطالبة المستخدم بتوفير بيانات الاعتماد الخاصة به ويتم إعادة توجيهه على الفور إلى Microsoft Azure Active Directory B2C باستخدام رمز مميز على فيسبوك.

جلسة عمل التطبيق

يمكن حماية تطبيق الويب أو تطبيق الهاتف المحمول أو الصفحة الواحدة بواسطة رمز مميز للوصول OAuth2 أو رمز هوية مميز أو رمز SAML المميز. وعندما يحاول أحد المستخدمين الوصول إلى مورد محمي على التطبيق، يتحقق التطبيق مما إذا كانت هناك جلسة عمل نشطة على جانب التطبيق أو لا. وإذا لم تكن هناك جلسة تطبيق أو انتهت مدة صلاحية الجلسة، فسينقل التطبيق المستخدم إلى صفحة تسجيل الدخول لـ Microsoft Azure Active Directory B2C.

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

تكوين سلوك جلسة عمل Microsoft Azure Active Directory B2C

يمكنك تكوين سلوك جلسة عمل Microsoft Azure Active Directory B2C، بما في ذلك:

• مدة بقاء جلسة عمل تطبيق الويب (بالدقائق) -وهي مقدار الوقت الذي يتم فيه تخزين ملف تعريف ارتباط جلسة عمل Microsoft Azure Active Directory B2C على متصفح المستخدم بعد المصادقة الناجحة. يمكنك تعيين مدة جلسة العمل حتى 24 ساعة.

• مهلة جلسة عمل تطبيق الويب - تشير إلى كيفية تمديد جلسة العمل بواسطة إعداد مدة جلسة العمل أو إعداد الاحتفاظ بتسجيل الدخول (KMSI).

  • التجميع - يشير إلى أن جلسة العمل يتم تمديدها في كل مرة يقوم فيها المستخدم بإجراء مصادقة مستندة إلى ملفات تعريف الارتباط (افتراضي).
  • المطلقة - يشير إلى أن المستخدم مجبر على إعادة المصادقة بعد الفترة الزمنية المحددة.

• تكوين تسجيل الدخول الأحادي - يمكن تكوين جلسة عمل Microsoft Azure Active Directory B2C باستخدام النطاقات التالية:

  • المستأجر - يُعد هذا الإعداد هو الإعداد الافتراضي. يسمح استخدام هذا الإعداد للعديد من التطبيقات وتدفق المستخدم في مستأجر B2C الخاص بك بمشاركة جلسة المستخدم نفسها. فعلى سبيل المثال، بمجرد تسجيل دخول المستخدم إلى أحد التطبيقات، يمكن للمستخدم أيضاً تسجيل الدخول بسلاسة إلى تطبيق آخر عند الوصول إليه.
  • التطبيق - يسمح لك هذا الإعداد بالاحتفاظ بجلسة عمل أحد المستخدمين لأحد التطبيقات حصرياً، بغض النظر عن التطبيقات الأخرى. فعلى سبيل المثال، يمكنك استخدام هذا الإعداد إذا كنت تريد أن يقوم المستخدم بتسجيل الدخول إلى Contoso Pharmacy بغض النظر عما إذا كان المستخدم قد قام بتسجيل الدخول بالفعل إلى Contoso Groceries أو لا.
  • النهج - يسمح لك هذا الإعداد بالاحتفاظ بجلسة عمل المستخدم حصرياً لتدفق المستخدم، بغض النظر عن التطبيقات التي تستخدمها. فعلى سبيل المثال، إذا قام المستخدم بتسجيل الدخول بالفعل وأكمل إحدى خطوات المصادقة متعددة العوامل (MFA)، فعندئذٍ يمكن منح المستخدم حق الوصول إلى أجزاء من تطبيقات متعددة ذات أمان أعلى، طالما لا تنتهي صلاحية جلسة العمل المرتبطة بتدفق المستخدم.
  • الممنوع - يفرض هذا الإعداد على المستخدم المرور عبر تدفق المستخدم بالكامل عند كل تنفيذ للنهج.

تكوين تدفق المستخدم

لتكوين سلوك جلسة العمل في تدفق المستخدم لديك، اتبع الخطوات التالية:

1. تسجيل الدخول إلى ⁧⁩مدخل Azure⁧⁩.
2. تأكد من استخدامك الدليل الذي يحتوي على مستأجر Azure AD B2C لديك. حدّد أيقونة Directories + subscriptionsفي شريط أدوات المدخل.
3. في صفحة Portal settings | Directories + subscriptions ابحث عن دليل Azure AD B2C في قائمة Directory name ثم حدّد Switch.
4. اختر "All services" الموجودة في الزاوية العلويةِ اليسرى من مدخل Microsoft Azure، ثم ابحث عن Microsoft Azure Active Directory B2Cوحدده.
5. حدد "User flows" .
6. افتح تدفق المستخدم الذي قمت بإنشائه سابقاً.
7. حدد «خصائص».
8. قم بتكوين مدة بقاء جلسة عمل تطبيق الويب (بالدقائق)، ومهلة جلسة عمل تطبيق الويب، وتكوين تسجيل الدخول الأحادي، وطلب رمز المعرف المميز في طلبات تسجيل الخروج حسب الحاجة.
9. اضغط على حفظ .

تكوين النهج المخصص

لتكوين سلوك جلسة العمل في النهج المخصص لديك، اتبع الخطوات التالية:

1. افتح ملف جهة الاعتماد (RP)، على سبيل المثال SignUpOrSignin.xml

2. إذا لم يكن موجوداً بالفعل، فأضِف العنصر <UserJourneyBehaviors> التالي إلى العنصر <RelyingParty>. يجب أن يكون موجوداً فوراً بعد <DefaultUserJourney ReferenceId="UserJourney Id"/>.

   <UserJourneyBehaviors>
     <SingleSignOn Scope="Application" />
     <SessionExpiryType>Absolute</SessionExpiryType>
     <SessionExpiryInSeconds>86400</SessionExpiryInSeconds>
   </UserJourneyBehaviors>
   

   بعد إضافة عناصر سلوك رحلة المستخدم، يجب أن يبدو العنصر RelyingParty مثل المثال التالي:

   <RelyingParty>
     <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
     <UserJourneyBehaviors>
       <SingleSignOn Scope="Application" />
       <SessionExpiryType>Absolute</SessionExpiryType>
       <SessionExpiryInSeconds>86400</SessionExpiryInSeconds>
     </UserJourneyBehaviors>
     <TechnicalProfile Id="PolicyProfile">
       <DisplayName>PolicyProfile</DisplayName>
       <Protocol Name="OpenIdConnect" />
       <OutputClaims>
         <OutputClaim ClaimTypeReferenceId="displayName" />
         <OutputClaim ClaimTypeReferenceId="givenName" />
         ...
       </OutputClaims>
       <SubjectNamingInfo ClaimType="sub" />
     </TechnicalProfile>
   </RelyingParty>
   

3. تغيير قيمة السمة Scope إلى إحدى القيم المحتملة: Suppressed، Tenant، Applicationأو Policy. لمزيد من المعلومات، راجع المقالة المرجعية RelyingParty.

4. اضبط العنصر SessionExpiryType إلى Rolling أو Absolute. لمزيد من المعلومات، راجع المقالة المرجعية RelyingParty.

5. اضبط العنصر SessionExpiryInSeconds إلى قيمة رقمية بين 900 ثانية (15 دقيقة) و86400 ثانية (24 ساعة). لمزيد من المعلومات، راجع المقالة المرجعية RelyingParty.

تمكين ميزة "Keep me signed in" (KMSI)

يمكنك تمكين ميزة KMSI لمستخدمي موقع الويب والتطبيقات الأصلية الذين لديهم حسابات محلية في دليل Microsoft Azure Active Directory B2C. وعند تمكين الميزة، يمكن للمستخدمين اختيار البقاء مسجلين للدخول حتى تبقى الجلسة نشطة بعد إغلاق المتصفح. يتم الاحتفاظ بجلسة العمل عن طريق إعداد ملف تعريف ارتباط ثابت. يمكن للمستخدمين الذين حددوا ميزة KMSI، إعادة فتح المتصفح دون مطالبتهم بإعادة إدخال اسم المستخدم وكلمة المرور الخاصة بهم. يتم إبطال هذا الوصول (ملف تعريف الارتباط الدائم) عند تسجيل خروج المستخدم. لمزيد من المعلومات، تحقق من العرض التوضيحي المباشر.

تُعد ميزة KMSI قابلة للتكوين على مستوى تدفق المستخدم الفردي. وقبل تمكين KMSI لتدفق المستخدم الخاص بك، خذ ما يلي بعين الاعتبار:

• يتم دعم ميزة KMSI للإصدارات الموصى بها من التسجيل وتسجيل الدخول (SUSI) وتسجيل الدخول وتدفقات المستخدمين لتحرير ملفات التعريف فقط. إذا كان لديك حالياً إصدارات قياسية (قديمة) أو معاينة قديمة - الإصدار 2 من تدفقات المستخدم هذه وتريد تمكين ميزة KMSI، فستحتاج إلى إنشاء إصدارات جديدة، موصى بها من تدفقات المستخدم هذه.
• ولا تُدعم ميزة KMSI مع إعادة تعيين كلمة المرور أو تدفق المستخدم للتسجيل.
• وإذا كنت ترغب في تمكين ميزة KMSI لكل التطبيقات في المستأجر الخاص بك، لذا نوصي بتمكين ميزة KMSI لجميع تدفقات المستخدم في المستأجر الخاص بك. ونظراً لأنه يمكن تقديم نُهج متعددة للمستخدم أثناء الجلسة، فمن المحتمل أن يواجهوا نُهج لم يتم تمكين ميزة KMSI بها، ما قد يؤدي إلى إزالة ملف تعريف الارتباط لميزة KMSI من الجلسة.
• ويجب عدم تمكين ميزة KMSI على أجهزة الكمبيوتر العامة.

تكوين KMSI لتدفق المستخدم

لتمكين ميزة KMSI لتدفق المستخدم الخاص بك:

1. تسجيل الدخول إلى ⁧⁩مدخل Azure⁧⁩.

2. تأكد من استخدامك الدليل الذي يحتوي على مستأجر Azure AD B2C لديك. حدّد أيقونة Directories + subscriptionsفي شريط أدوات المدخل.

3. في صفحة Portal settings | Directories + subscriptions ابحث عن دليل Azure AD B2C في قائمة Directory name ثم حدّد Switch.

4. اختر كل الخدمات في الزاوية العلويةِ اليسرى من مدخل Microsoft Azure، ثم ابحث عن Microsoft Microsoft Azure Active Directory B2C وحدده.

5. حدد تدفق المستخدم (النُهج) .

6. افتح تدفق المستخدم الذي قمت بإنشائه سابقًا.

7. حدد «خصائص».

8. ضمن Session behavior، حدد Enable keep me signed in session. بجوار "Keep me signed in session (days)"، أدخل قيمة من 1 إلى 90 لتحديد عدد الأيام التي يمكن أن تظل فيها الجلسة مفتوحة.

   

يجب على المستخدمين عدم تمكين هذا الخيار على أجهزة الكمبيوتر العامة.

تكوين معرف الصفحة

لتمكين KMSI، اضبط عنصر تعريف المحتوى DataUri على page identifierunifiedssp وpage version1.1.0 أو أعلى.

1. افتح ملف ملحقات النهج الخاص بك. على سبيل المثال، ⁧SocialAndLocalAccounts/TrustFrameworkExtensions.xml⁩. يعد ملف الملحق هذا أحد ملفات النهج المضمنة في حزمة بدء النهج المخصص، والتي يجب أن تحصل عليها في المتطلب الأساسي، البدء بالنُهج المخصصة.

2. ابحث عن عنصر BuildingBlocks. إذا لم يكن العنصر موجوداً، فقم بإضافته.

3. أضف عنصر ContentDefinitions إلى عنصر BuildingBlocks الخاص بالنهج.

   يجب أن يبدو نهجك المخصص مثل القصاصة البرمجية التالية:

   <BuildingBlocks>
     <ContentDefinitions>
       <ContentDefinition Id="api.signuporsignin">
         <DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.1.0</DataUri>
       </ContentDefinition>
     </ContentDefinitions>
   </BuildingBlocks>
   

إضافة بيانات التعريف إلى ملف التعريف الفني المؤكد ذاتياً

لإضافة خانة اختيار ميزة KMSI إلى صفحة التسجيل وتسجيل الدخول، قم بتعيين بيانات التعريف setting.enableRememberMe إلى "true". تجاوز ملفات التعريف الفنية SelfAsserted-LocalAccountSignin-Email في ملف الملحق.

1. ابحث عن عنصر ClaimsProviders. إذا كان العنصر غير موجود، قم بإضافته.
2. أضف موفرو المطالبات التالية إلى عنصر ClaimsProviders:

<ClaimsProvider>
  <DisplayName>Local Account</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
      <Metadata>
        <Item Key="setting.enableRememberMe">True</Item>
      </Metadata>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

1. احفظ ملف الملحقات.

تكوين أحد ملفات جهة اعتماد

قم بتحديث ملف جهة الاعتماد (RP) الذي يبدأ رحلة المستخدم التي قمت بإنشائها. تسمح لك المعلمة keepAliveInDays بتكوين المدة التي يجب أن يستمر فيها ملف تعريف ارتباط الخاص بجلسة ميزة البقاء مسجلاً للدخول (KMSI). فعلى سبيل المثال، إذا قمت بتعيين القيمة إلى 30، فعندئذٍ سوف يستمر ملف تعريف ارتباط جلسة عمل KMSI لمدة 30 يوماً. ويتراوح نطاق القيمة من يوم واحد إلى 90 يوماً. كما يؤدي تعيين القيمة إلى 0 إلى إيقاف تشغيل وظيفة KMSI.

1. افتح ملف النهج المخصص لديك. على سبيل المثال، SignUpOrSignin.xml.

2. إذا لم تكن موجودة بالفعل، فأضف عقدة <UserJourneyBehaviors> التابعة إلى العقدة <RelyingParty>. يجب أن يكون موجوداً فوراً بعد <DefaultUserJourney ReferenceId="User journey Id" />، مثل: <DefaultUserJourney ReferenceId="SignUpOrSignIn" />.

3. أضف العقدة التالية كتابعة للعنصر <UserJourneyBehaviors>.

   <UserJourneyBehaviors>
     <SingleSignOn Scope="Tenant" KeepAliveInDays="30" />
     <SessionExpiryType>Absolute</SessionExpiryType>
     <SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
   </UserJourneyBehaviors>
   

يمكنك تعيين كلٍ من KeepAliveInDays و SessionExpiryInSeconds بحيث أنه إذا مكَّن المستخدم KMSI أثناء تسجيل الدخول، يُستخدَم KeepAliveInDays لتعيين ملفات تعريف الارتباط، وإلا تُستخدم القيمة المحددة في المعلمة SessionExpiryInSeconds. نوصي بتعيين قيمة SessionExpiryInSeconds لتكون فترة قصيرة (1200 ثانية)، بينما يمكن تعيين قيمة KeepAliveInDays إلى فترة طويلة نسبياً (30 يوماً)، كما هو موضح في المثال التالي:

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <UserJourneyBehaviors>
    <SingleSignOn Scope="Tenant" KeepAliveInDays="30" />
    <SessionExpiryType>Absolute</SessionExpiryType>
    <SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
  </UserJourneyBehaviors>
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
      <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

‏‏تسجيل الخروج

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

بناء على طلب تسجيل الخروج، فإن Microsoft Azure Active Directory B2C:

1. يقوم بإبطال جلسة العمل المستندة إلى ملف تعريف الارتباط لـ Microsoft Azure Active Directory B2C.
2. يحاول تسجيل الخروج من موفري الهوية الموحدة.

1. يقوم بإبطال جلسة العمل المستندة إلى ملف تعريف الارتباط لـ Microsoft Azure Active Directory B2C.
2. يحاول تسجيل الخروج من موفري الهوية الموحدة:
   • OpenId Connect - إذا كانت نقطة نهاية التكوين المعروفة لموفر الهوية تحدد موقع end_session_endpoint. لا يجتاز طلب تسجيل الخروج المعلمة id_token_hint. إذا كان موفر الهوية الموحدة يتطلب هذه المعلمة، فسيفشل طلب تسجيل الخروج.
   • OAuth2 - إذا كانت بيانات التعريف لموفر الهوية تحتوي على الموقع end_session_endpoint.
   • SAML - إذا كانت بيانات التعريف لموفر الهوية تحتوي على الموقع SingleLogoutService.
3. يسجّل الخروج من التطبيقات الأخرى بشكل اختياري. لمزيد من المعلومات، راجع قسم تسجيل الخروج الأحادي.

ملاحظة

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

يؤدي تسجيل الخروج إلى مسح حالة تسجيل الدخول الأحادي للمستخدم باستخدام Microsoft Azure Active Directory B2C، لكنه قد لا يقوم بتسجيل خروج المستخدم من جلسة موفر الهوية الاجتماعية الخاصة به. وإذا حدد المستخدم موفر الهوية نفسه أثناء عملية تسجيل دخول لاحقة، فعندئذٍ قد تتم إعادة مصادقة المستخدم، دون إدخال بيانات اعتماده. إذا أراد المستخدم تسجيل الخروج من التطبيق، فهذا لا يعني بالضرورة أنه يريد تسجيل الخروج من حسابه على فيسبوك. ومع ذلك، إذا تم استخدام الحسابات المحلية، تنتهي جلسة عمل المستخدم بشكل صحيح.

تسجيل الدخول الأحادي

عند إعادة توجيه المستخدم إلى نقطة نهاية تسجيل الخروج من Azure AD B2C (لكل من OAuth2 وOpenID Connect) أو إرسال LogoutRequest (لـ SAML)، فإن Azure AD B2C يمسح جلسة المستخدم من المتصفح. ومع ذلك، قد يظل المستخدم قيد تسجيل الدخول إلى تطبيقات أخرى تستخدم Azure AD B2C للمصادقة. لتسجيل خروج المستخدم من جميع التطبيقات التي لها جلسة نشطة، فإن Microsoft Azure Active Directory B2C يدعم تسجيل الخروج الفردي، المعروف أيضاً باسم تسجيل الخروج الأحادي (SLO) .

أثناء تسجيل الخروج، يرسل Microsoft Azure Active Directory B2C طلب HTTP في الوقت نفسه إلى عنوان URL الخاص بتسجيل الخروج المسجل لجميع التطبيقات التي قام المستخدم بتسجيل الدخول إليها حالياً.

تكوين نهجك المخصص

لدعم تسجيل الخروج الفردي، يجب أن تحدد الملفات التعريف الفنية لجهة إصدار الرمز المميز لكل من JWT وSAML:

• اسم البروتوكول، مثل <Protocol Name="OpenIdConnect" />
• الإشارة إلى ملف التعريف الفني للجلسة، مثل UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />.

يوضح المثال التالي جهتي إصدار الرمز المميز JWT وSAML مع تسجيل الخروج المفرد:

<ClaimsProvider>
  <DisplayName>Local Account SignIn</DisplayName>
  <TechnicalProfiles>
    <!-- JWT Token Issuer -->
    <TechnicalProfile Id="JwtIssuer">
      <DisplayName>JWT token Issuer</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <OutputTokenFormat>JWT</OutputTokenFormat>
      ...    
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
    </TechnicalProfile>

    <!-- Session management technical profile for OIDC based tokens -->
    <TechnicalProfile Id="SM-jwt-issuer">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.OAuthSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </TechnicalProfile>

    <!--SAML token issuer-->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>SAML token issuer</DisplayName>
      <Protocol Name="SAML2" />
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      ...
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer" />
    </TechnicalProfile>

    <!-- Session management technical profile for SAML based tokens -->
    <TechnicalProfile Id="SM-Saml-issuer">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

تكوين تطبيقك

من أجل أن يشارك التطبيق في تسجيل الخروج الفردي:

• لموفري خدمة SAML، قم بتكوين التطبيق باستخدام موقع SingleLogoutService في مستند بيانات تعريف SAML الخاص به. يمكنك أيضاً تكوين عملية تسجيل التطبيق logoutUrl. لمزيد من المعلومات، راجع تعيين عنوا URL الخاص بتسجيل الخروج.
• وبالنسبة إلى تطبيقات OpenID Connect أو OAuth2، قم بتعيين السمة logoutUrl الخاصة ببيان تسجيل التطبيق. لتكوين URL الخاص بتسجيل الخروج:
  1. من قائمة Microsoft Azure Active Directory B2C، حدد "App registrations" .
  2. حدد تسجيل تطبيقك.
  3. ضمن "Manage"، حدد "Authentication".
  4. ضمن "Front-channel logout URL"، قم بتكوين عنوان URL الخاص بتسجيل الخروج.

معالجة طلبات تسجيل الخروج الفردي

عندما يتلقى Microsoft Azure Active Directory B2C طلب تسجيل الخروج، فإنه يستخدم HTML iframe للقناة الأمامية لإرسال طلب HTTP إلى URL الخاص بتسجيل الخروج لكل تطبيق مشارك التي يُعد المستخدم مسجلاً للدخول فيه حالياً. ملاحظة، لن يحصل التطبيق الذي يقوم بتشغيل طلب تسجيل الخروج على رسالة تسجيل الخروج هذه. يجب أن تستجيب التطبيقات لطلب تسجيل الخروج عن طريق مسح جلسة عمل التطبيق التي تُعرّف المستخدم.

• بالنسبة لتطبيقات OpenID Connect وOAuth2، يرسل Microsoft Azure Active Directory B2C طلب HTTP GET إلى عنوان URL المسجل لتسجيل الخروج.
• وبالنسبة لتطبيقات SAML، يرسل Microsoft Azure Active Directory B2C طلب تسجيل الخروج SAML إلى عنوان URL المسجل.

وعند إعلام جميع التطبيقات بتسجيل الخروج، سيقوم Microsoft Azure Active Directory B2C بإجراء أحد ما يلي:

• بالنسبة لتطبيقات OpenID Connect أو OAuth2، تتم إعادة توجيه المستخدم إلى post_logout_redirect_uri المطلوب بما في ذلك المعلمة (الاختيارية) state المحددة في الطلب الأولي. على سبيل المثالhttps://contoso.com/logout?state=foo.
• وبالنسبة لتطبيقات SAML، يتم إرسال استجابة تسجيل خروج لـ SAML عبر HTTP POST إلى التطبيق الذي أرسل طلب الخروج في البداية.

تأمين إعادة توجيه تسجيل خروجك

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

ولطلب رمز مميز للمعرّف في طلبات الخروج:

1. تسجيل الدخول إلى ⁧⁩مدخل Azure⁧⁩.
2. تأكد من استخدامك الدليل الذي يحتوي على مستأجر Azure AD B2C لديك. حدّد أيقونة Directories + subscriptionsفي شريط أدوات المدخل.
3. في صفحة Portal settings | Directories + subscriptions ابحث عن دليل Azure AD B2C في قائمة Directory name ثم حدّد Switch.
4. اختر "All services" الموجودة في الزاوية العلويةِ اليسرى من مدخل Microsoft Azure، ثم ابحث عن Microsoft Azure Active Directory B2Cوحدده.
5. حدد "User flows" .
6. افتح تدفق المستخدم الذي قمت بإنشائه سابقاً.
7. حدد «خصائص».
8. تمكين الرمز المميز للمعرف المطلوب في طلبات تسجيل الخروج.
9. ارجع إلى Microsoft Azure AD B2C.
10. حدد "App registrations"، ثم حدد تطبيقك.
11. تحديد المصادقة
12. في مربع النص URL Logout، اكتب عنوان URI الخاص بإعادة توجيه تسجيل الخروج لمنشورك، ثم حدد "Save" .

لطلب رمز مميز للمعرّف في طلبات تسجيل الخروج، أضف عنصر UserJourneyBehaviors داخل عنصر RelyingParty. ثم قم بتعيين عنصر EnforceIdTokenHintOnLogout الخاص بـ SingleSignOn إلى true. لمزيد من المعلومات، تحقق من العرض التوضيحي المباشر. يجب أن يبدو عنصر UserJourneyBehaviors لديك مثل هذا المثال:

<UserJourneyBehaviors>
  <SingleSignOn Scope="Tenant" EnforceIdTokenHintOnLogout="true"/>
</UserJourneyBehaviors>

لتكوين URL الخاص بتسجيل الخروج من التطبيق الخاص بك:

1. تسجيل الدخول إلى ⁧⁩مدخل Azure⁧⁩.
2. تأكد من استخدامك الدليل الذي يحتوي على مستأجر Azure AD B2C لديك. حدّد أيقونة Directories + subscriptionsفي شريط أدوات المدخل.
3. في صفحة Portal settings | Directories + subscriptions ابحث عن دليل Azure AD B2C في قائمة Directory name ثم حدّد Switch.
4. اختر "All services" الموجودة في الزاوية العلويةِ اليسرى من مدخل Microsoft Azure، ثم ابحث عن Microsoft Azure Active Directory B2Cوحدده.
5. حدد "App registrations"، ثم حدد تطبيقك.
6. تحديد المصادقة
7. في مربع النص URL Logout، اكتب عنوان URI الخاص بإعادة توجيه تسجيل الخروج لمنشورك، ثم حدد "Save" .

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

• تعرف على كيفية تكوين الرموز المميزة في Microsoft Azure Active Directory B2C.