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

مقالة
11/20/2023

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

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

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

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

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

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

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

نظرة عامة على جلسة عمل Azure AD B2C

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

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

SSO session

جلسة Azure AD B2C

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

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

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

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

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

فكر في السيناريو التالي:

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

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

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

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

تكوين سلوك جلسة عمل Azure AD B2C

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

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

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

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

سجل دخولك إلى مدخل Azure.
إذا كان لديك حق الوصول إلى عدة مستأجرين، فحدد رمز الإعدادات في القائمة العلوية للتبديل إلى مستأجر Azure AD B2C من قائمة Directories + subscriptions.
اختر كل الخدمات في الزاوية العلويةِ اليسرى من مدخل Microsoft Azure، ثم ابحث عن Azure AD B2Cوحدده.
حدد «متصفحات المستخدم» .
افتح تدفق المستخدم الذي قمت بإنشائه سابقاً.
حدد الخصائص.
قم بتكوين مدة بقاء جلسة عمل تطبيق الويب (بالدقائق)، ومهلة جلسة عمل تطبيق الويب، وتكوين تسجيل الدخول الأحادي، وطلب رمز المعرف المميز في طلبات تسجيل الخروج حسب الحاجة.
انقر فوق حفظ.

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

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

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

إذا لم يكن موجوداً بالفعل، فأضِف العنصر <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>

تغيير قيمة السمة Scope إلى إحدى القيم المحتملة: Suppressed، Tenant، Applicationأو Policy. لمزيد من المعلومات، راجع المقالة المرجعية RelyingParty.
اضبط العنصر SessionExpiryType إلى Rolling أو Absolute. لمزيد من المعلومات، راجع المقالة المرجعية RelyingParty.
اضبط العنصر SessionExpiryInSeconds إلى قيمة رقمية بين 900 ثانية (15 دقيقة) و86400 ثانية (24 ساعة). لمزيد من المعلومات، راجع المقالة المرجعية RelyingParty.

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

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

Example sign-up sign-in page showing a Keep me signed in checkbox

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

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

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

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

سجل دخولك إلى مدخل Azure.
إذا كان لديك حق الوصول إلى عدة مستأجرين، فحدد رمز الإعدادات في القائمة العلوية للتبديل إلى مستأجر Azure AD B2C من قائمة Directories + subscriptions.
اختر كل الخدمات في الزاوية العلويةِ اليسرى من مدخل Microsoft Azure، ثم ابحث عن Azure AD B2Cوحدده.
حدد تدفق المستخدم (النُهج).
افتح تدفق المستخدم الذي قمت بإنشائه سابقاً.
حدد الخصائص.
ضمن Session behavior، حدد Enable keep me signed in session. بجوار "Keep me signed in session (days)"، أدخل قيمة من 1 إلى 90 لتحديد عدد الأيام التي يمكن أن تظل فيها الجلسة مفتوحة.

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

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

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

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

أضف عنصر 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 في ملف الملحق.

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

أضف موفرو المطالبات التالية إلى عنصر ClaimsProviders:

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

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

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

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

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

أضف العقدة التالية كتابعة للعنصر <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>

تسجيل الخروج

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

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

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

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

إشعار

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

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

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

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

أثناء تسجيل الخروج، يرسل Azure AD 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. من قائمة Azure AD B2C، حدد "App registrations".
2. حدد تسجيل تطبيقك.
3. ضمن "Manage"، حدد "Authentication".
4. ضمن "Front-channel logout URL"، قم بتكوين عنوان URL الخاص بتسجيل الخروج.

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

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

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

عندما يقوم Azure AD B2C بإعلام جميع التطبيقات بتسجيل الخروج، فإنه يستمر في القيام بأحد الإجراءات التالية:

بالنسبة لتطبيقات OpenID الاتصال أو 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 للرد المطابق للتطبيق، يتم عرض رسالة خطأ ولا تتم إعادة توجيه المستخدم.

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

سجل دخولك إلى مدخل Azure.
إذا كان لديك حق الوصول إلى عدة مستأجرين، فحدد رمز الإعدادات في القائمة العلوية للتبديل إلى مستأجر Azure AD B2C من قائمة Directories + subscriptions.
اختر كل الخدمات في الزاوية العلويةِ اليسرى من مدخل Microsoft Azure، ثم ابحث عن Azure AD B2Cوحدده.
حدد «متصفحات المستخدم» .
افتح تدفق المستخدم الذي قمت بإنشائه سابقاً.
حدد الخصائص.
تمكين الرمز المميز للمعرف المطلوب في طلبات تسجيل الخروج.

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

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

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

حدد "App registrations"، ثم حدد تطبيقك.
تحديد المصادقة
في مربع النص URL Logout، اكتب عنوان URI الخاص بإعادة توجيه تسجيل الخروج لمنشورك، ثم حدد "Save".

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

تعرف على كيفية تكوين الرموز المميزة في Azure AD B2C.