مشاركة عبر

إدارة وصول المستخدم في Microsoft Azure Active Directory B2C

  • مقالة

تتناول هذه المقالة كيفية إدارة وصول المستخدم إلى التطبيقات الخاصة بك باستخدام Microsoft Azure Active Directory B2C (Microsoft Azure AD B2C). تتضمن إدارة الوصول في التطبيق الخاص بك:

  • التعرف على القصر والتحكم في وصول المستخدم إلى التطبيق الخاص بك.
  • اشتراط موافقة الوالدين للقصر باستخدام تطبيقاتك.
  • جمع بيانات الولادة والبلد/المنطقة من المستخدمين.
  • التقاط اتفاقية شروط الاستخدام والوصول إلى البوابات.

ملاحظة

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

التحكم في وصول القصر

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

إذا تم تعريف مستخدم على أنه قاصر، يمكنك تعيين تدفق المستخدم في Microsoft Azure Active Directory B2C إلى أحد الخيارات الثلاثة:

  • ارسل JWT id_token مرة أخرى إلى التطبيق:المستخدم مسجل في الدليل، ويتم إرجاع رمز مميز إلى التطبيق. ثم ينتقل التطبيق من خلال تطبيق قواعد العمل. على سبيل المثال، قد يستمر التطبيق في عملية موافقة الوالدين. لاستخدام هذا الأسلوب، اختر لتلقي مطالبات ageGroup وconsentProvidedForMinor من التطبيق.

  • إرسال رمز JSON المميز غير موقع إلى التطبيق:Microsoft Azure Active Directory B2C يعلم التطبيق بأن المستخدم قاصر ويوفر حالة موافقة الوالدين للمستخدم. ثم ينتقل التطبيق من خلال تطبيق قواعد العمل. لا يكمل رمز JSON المميز مصادقة ناجحة مع التطبيق. يجب أن يقوم التطبيق بمعالجة المستخدم غير المصادق عليه وفقا للمطالبات المضمنة في رمز JSON المميز والتي قد تتضمن الاسموالبريد الإلكترونيوageGroupوconsentProvidedForMinor.

  • حظر المستخدم: إذا كان المستخدم قاصرا ولم تُمنح موافقة الوالدين، يمكن لـMicrosoft Azure Active Directory B2C إعلام المستخدم بحظره. لا يتم إصدار رمز مميز ويتم حظر الوصول ولا يتم إنشاء حساب المستخدم أثناء رحلة التسجيل. لتنفيذ هذا الإعلام، يمكنك توفير صفحة محتوى HTML/CSS مناسبة لإعلام المستخدم وتقديم خيارات مناسبة. ولا يلزم اتخاذ أي إجراء آخر من خلال تطبيق التسجيلات الجديدة.

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

فيما يلي مثال لتدفق المستخدمين لجمع موافقة الوالدين:

  1. تعرف عملية واجهة برمجة تطبيقات Microsoft Graph المستخدم على أنه قاصر وتقوم بإرجاع بيانات المستخدم إلى التطبيق في شكل رمز JSON مميز غير موقع.

  2. يعالج التطبيق رمز JSON المميز ويعرض شاشة للقاصر ويخطره بأن موافقة الوالدين مطلوبة ويطلب موافقة أحد الوالدين عبر الإنترنت.

  3. Microsoft Azure Active Directory B2C يظهر رحلة تسجيل الدخول التي يمكن للمستخدم تسجيل الدخول إليها بشكل طبيعي ويصدر رمز مميز إلى التطبيق الذي تم تعيينه لتضمين egalAgeGroupClassification = "minorWithParentalConsent" . يجمع التطبيق عنوان البريد الإلكتروني للوالد ويتحقق من أن الوالد شخص بالغ. للقيام بذلك، يستخدم مصدرا موثوقا به، مثل مكتب معرف وطني/إقليمي أو التحقق من الترخيص أو إثبات بطاقة الائتمان. إذا تحقق من صحة ذلك، يطالب التطبيق القاصر بتسجيل الدخول باستخدام تدفق المستخدم Microsoft Azure Active Directory B2C. إذا تم رفض الموافقة (على سبيل المثال، إذا legalAgeGroupClassification = "minorWithoutParentalConsent")،يقوم Azure AD B2C بإرجاع رمز JSON المميز (وليس تسجيل دخول) إلى التطبيق لإعادة تشغيل عملية الموافقة. من الممكن اختياريا تخصيص تدفق المستخدم بحيث يمكن للقاصر أو البالغ استعادة الوصول إلى حساب القاصر عن طريق إرسال رمز تسجيل إلى عنوان البريد الإلكتروني للقاصر أو عنوان البريد الإلكتروني للبالغ المسجل.

  4. يقدم التطبيق خيارا للقاصر بإلغاء الموافقة.

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

للحصول على مزيد من المعلومات حول legalAgeGroupClassificationوconsentProvidedForMinor و ageGroup، راجع نوع مورد المستخدم. للحصول على مزيد من المعلومات حول السمات المخصصة، راجع استخدام السمات المخصصة لجمع معلومات حول المستهلكين الخاصين بك. عند معالجة السمات الموسعة باستخدام واجهة برمجة تطبيقات Microsoft Graph، يجب عليك استخدام الإصدار الطويل للسمة مثل extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth: 2011-01-01T00:00:00Z.

جمع تاريخ الميلاد وبيانات البلد/المنطقة

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

يمكن لتدفق المستخدم المخصص جمع معلومات تاريخ الميلاد والبلد /المنطقة واستخدام تحويل مطالبات Microsoft Azure Active Directory B2C لتحديد ageGroup واستمرار النتيجة (أو استمرار تاريخ الميلاد ومعلومات البلد / المنطقة مباشرة) في الدليل.

توضح الخطوات التالية المنطق المستخدم لحساب ageGroup من تاريخ ميلاد المستخدم:

  1. حاول العثور على البلد/المنطقة حسب رمز البلد/المنطقة في القائمة. إذا لم يتم العثور على البلد/المنطقة، تراجع إلى الافتراضي.

  2. إذا كانت العقدة MinorConsent موجودة في عنصر البلد/المنطقة:

    أ. احسب التاريخ الذي يجب أن يكون المستخدم قد ولد فيه لكي يعتبر بالغا. على سبيل المثال، إذا كان التاريخ الحالي هو 14 مارس 2015، وكان تاريخ MinorConsent هو 18، يجب ألا يتجاوز تاريخ الميلاد 14 مارس 2000.

    ب. قارن الحد الأدنى لتاريخ الميلاد بتاريخ الميلاد الفعلي. إذا كان الحد الأدنى لتاريخ الميلاد قبل تاريخ ميلاد المستخدم، فإن الحساب يُرجع القاصر كحساب الفئة العمرية.

  3. إذا كانت العقدة MinorNoConsentRequired موجودة في عنصر البلد/المنطقة، كرر الخطوتين 2أ و2ب باستخدام القيمة من MinorNoConsentRequired. يرجع الإخراج 2b MinorNoConsentRequired إذا كان الحد الأدنى لتاريخ الميلاد قبل تاريخ ميلاد المستخدم.

  4. إذا لم يرجع أي من الحسابين صوابا، فإن الحساب يرجعبالغ.

إذا كان أحد التطبيقات قد جمع بيانات تاريخ الميلاد أو البلد/المنطقة بشكل موثوق بواسطة أساليب أخرى، قد يستخدم التطبيق واجهة برمجة تطبيقات Graph لتحديث سجل المستخدم بهذه المعلومات. على سبيل المثال:

  • إذا كان المستخدم معروفا بأن يكون بالغا، حدث سمة الدليلageGroup مع قيمة البالغ.
  • إذا عُلم أن أحد المستخدمين قاصر السن، فحدِّث سمة الدليل ageGroup بقيمة Minor وعيِّن consentProvidedForMinor، حسب المطلوب.

قواعد حساب القاصر

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

البلد/المنطقة اسم البلد/المنطقة سن موافقة القصر سن القصر
افتراضي بلا بلا 18
AE الإمارات العربية المتحدة بلا 21
AT النمسا 14 18
BE بلجيكا 14 18
BG بلغاريا 16 18
البوسنة والهرسك البحرين بلا 21
CM الكاميرون بلا 21
CY قبرص 16 18
التشيك جمهورية التشيك 16 18
DE ألمانيا 16 18
DK الدانمارك 16 18
EE إستونيا 16 18
EG مصر بلا 21
ES إسبانيا 13 18
FR فرنسا 16 18
بريطانيا المملكة المتحدة 13 18
GR اليونان 16 18
الموارد البشرية HR كرواتيا 16 18
HU المجر 16 18
IE أيرلندا 13 18
مسؤول تكنولوجيا المعلومات إيطاليا 16 18
KR جمهورية كوريا 14 18
LT ليتوانيا 16 18
LU لوكسمبورج 16 18
LV لاتفيا 16 18
MT مالطا 16 18
‏‏غير متوفر ناميبيا بلا 21
NL هولندا 16 18
PL بولندا 13 18
PT البرتغال 16 18
RO رومانيا 16 18
حد ذاته السويد 13 18
SG سنغافورة بلا 21
SI سلوفينيا 16 18
SK سلوفاكيا 16 18
TD تشاد بلا 21
TH تايلاند بلا 20
TW تايوان بلا 20
الولايات المتحدة الولايات المتحدة 13 18

تسجيل اتفاقية شروط الاستخدام

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

قد تتضمنشروط الاستخدام أيضاً "الموافقة على مشاركة البيانات مع جهات خارجية". بناءً على اللوائح المحلية وقواعد العمل، يمكنك جمع قبول المستخدم لكلا الشرطين مجتمعين، أو يمكنك السماح للمستخدم بقبول شرط دون الآخر.

تصف الخطوات التالية كيفية إدارة شروط الاستخدام:

  1. سجل قبول شروط الاستخدام وتاريخ القبول باستخدام واجهة برمجة التطبيقات Graph والسمات الموسعة. يمكنك القيام بذلك باستخدام كل من تدفقات المستخدم المضمنة والنهج المخصصة. نوصي بإنشاء واستخدام سمات extension_termsOfUseConsentDateTimeextension_termsOfUseConsentVersion.

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

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

  4. يتطلب قبول شروط الاستخدام المحدثة من خلال مقارنة تاريخ القبول بتاريخ أحدث إصدار لشروط الاستخدام. يمكنك مقارنة التواريخ فقط باستخدام تدفق مستخدم مخصص. استخدم السمة الموسعة extension_termsOfUseConsentDateTime وقارن القيمة بالمطالبة termsOfUseTextUpdateDateTime. إذا كان القبول قديما، افرض قبولا جديدا من خلال عرض شاشة مؤكدة ذاتيا. وإلا، احظر الوصول باستخدام منطق النهج.

  5. تتطلب قبول شروط الاستخدام المحدثة من خلال مقارنة رقم إصدار القبول برقم الإصدار المقبول الأحدث. يمكنك مقارنة أرقام الإصدار فقط باستخدام تدفق مستخدم مخصص. استخدم السمة الموسعة extension_termsOfUseConsentDateTime وقارن القيمة بالمطالبة extension_termsOfUseConsentVersion. إذا كان القبول قديما، افرض قبولا جديدا من خلال عرض شاشة مؤكدة ذاتيا. وإلا، احظر الوصول باستخدام منطق النهج.

يمكنك تسجيل قبول شروط الاستخدام ضمن السيناريوهات التالية:

  • يسجل أي مستخدم جديد. يتم عرض شروط الاستخدام، ويتم تخزين نتيجة القبول.
  • يقوم المستخدم بتسجيل الدخول والذي قبل مسبقا شروط الاستخدام الأحدث أو النشطة. لا يتم عرض شروط الاستخدام.
  • يقوم المستخدم بتسجيل الدخول ولم يقبل شروط الاستخدام الأحدث أو النشطة. يتم عرض شروط الاستخدام، ويتم تخزين نتيجة القبول.
  • يقوم المستخدم بتسجيل الدخول وقد قبل إصدارا قديما من شروط الاستخدام، والتي يتم تحديثها الآن إلى أحدث إصدار. يتم عرض شروط الاستخدام، ويتم تخزين نتيجة القبول.

تعرض الصورة التالية تدفق المستخدم الموصى به:

يوضح مخطط التدفق تدفق المستخدم المقبول الموصى به

وفيما يلي مثال على الموافقة على شروط الاستخدام المستندة إلى التاريخ في مطالبة. إذا كانت extension_termsOfUseConsentDateTime المطالبة أقدم من 2025-01-15T00:00:00، افرض قبول جديد عن طريق التحقق من termsOfUseConsentRequired المطالبة المنطقية وعرض شاشة ذاتية التأكيد.

<ClaimsTransformations>
  <ClaimsTransformation Id="GetNewUserAgreeToTermsOfUseConsentDateTime" TransformationMethod="GetCurrentDateTime">
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentDateTime" TransformationClaimType="currentDateTime" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="IsTermsOfUseConsentRequired" TransformationMethod="IsTermsOfUseConsentRequired">
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="extension_termsOfUseConsentDateTime" TransformationClaimType="termsOfUseConsentDateTime" />
    </InputClaims>
    <InputParameters>
      <InputParameter Id="termsOfUseTextUpdateDateTime" DataType="dateTime" Value="2025-01-15T00:00:00" />
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="termsOfUseConsentRequired" TransformationClaimType="result" />
    </OutputClaims>
  </ClaimsTransformation>
</ClaimsTransformations>

وفيما يلي مثال على الموافقة على شروط الاستخدام المستندة إلى إصدار في مطالبة. إذا كانت extension_termsOfUseConsentVersion المطالبة تساوي V1، افرض قبول جديد عن طريق التحقق من termsOfUseConsentRequired المطالبة المنطقية وعرض شاشة ذاتية التأكيد.

<ClaimsTransformations>
  <ClaimsTransformation Id="GetEmptyTermsOfUseConsentVersionForNewUser" TransformationMethod="CreateStringClaim">
    <InputParameters>
      <InputParameter Id="value" DataType="string" Value=""/>
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="createdClaim" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="GetNewUserAgreeToTermsOfUseConsentVersion" TransformationMethod="CreateStringClaim">
    <InputParameters>
      <InputParameter Id="value" DataType="string" Value="V1"/>
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="createdClaim" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="IsTermsOfUseConsentRequiredForVersion" TransformationMethod="CompareClaimToValue">
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="inputClaim1" />
    </InputClaims>
    <InputParameters>
      <InputParameter Id="compareTo" DataType="string" Value="V1" />
      <InputParameter Id="operator" DataType="string" Value="not equal" />
      <InputParameter Id="ignoreCase" DataType="string" Value="true" />
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="termsOfUseConsentRequired" TransformationClaimType="outputClaim" />
    </OutputClaims>
  </ClaimsTransformation>
</ClaimsTransformations>

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