ترحيل المستخدمين إلى AAD (دليل Azure النشط) متاجرة عمل-مستهلك
قد يتطلب الترحيل من موفر هوية آخر إلى AAD (دليل Azure النشط) متاجرة عمل-مستهلك أيضاً ترحيل حسابات المستخدمين الموجودة. تتم مناقشة أسلوبين للترحيل هنا، ما قبل الترحيل والترحيل السلس. مع أي من النهجين، يطلب منك كتابة تطبيق أو برنامج نصي يستخدم Microsoft Graph API لإنشاء حسابات المستخدمين في AAD (دليل Azure النشط) متاجرة عمل-مستهلك.
شاهد هذا الفيديو للتعرف على الإستراتيجيات والخطوات المتبعة في ترحيل المستخدمين في AAD (دليل Azure النشط) متاجرة عمل-مستهلك.
ملاحظة
قبل بدء الترحيل، تأكد من أن الحصة النسبية لمستأجر B2C Azure AD يمكن أن تستوعب جميع المستخدمين الذين تتوقع ترحيلهم. تعرف على كيفية الحصول على استخدام المستأجر الخاص بك. إذا كنت بحاجة إلى زيادة حد الحصة النسبية للمستأجر، فاتصل بدعم Microsoft.
ما قبل الترحيل
في تدفق ما قبل الترحيل، ينفذ تطبيق الترحيل الخطوات التالية لكل حساب مستخدم:
- قراءة حساب المستخدم من موفر الهوية القديم، بما في ذلك بيانات الاعتماد الحالية (اسم المستخدم وكلمة المرور).
- إنشاء حساب مطابق في دليل AAD (دليل Azure النشط) متاجرة عمل-مستهلك ببيانات الاعتماد الحالية.
استخدم تدفق ما قبل الترحيل في أي من هاتين الحالتين:
- لديك حق الوصول إلى النص غير المشفر لبيانات اعتماد المستخدم (اسم المستخدم وكلمة المرور الخاصة به).
- بيانات الاعتماد مشفرة، ولكن يمكنك فك تشفيرها.
للحصول على معلومات حول إنشاء حسابات المستخدمين برمجياً، راجع إدارة حسابات المستخدمين في AAD (دليل Azure النشط) متاجرة عمل-مستهلك مع Microsoft Graph.
الترحيل السلس
استخدم تدفق الترحيل السلس إذا لم يكن الوصول إلى النص غير المشفر لكلمات المرور في موفر الهوية القديم غير متوفر. على سبيل المثال، عندما:
- تكون كلمة المرور مخزنة في تنسيق مشفر أحادي الاتجاه، مثل دالة التجزئة.
- يتم تخزين كلمة المرور من قِبَل موفر الهوية القديم بطريقة لا يمكنك الوصول إليها. على سبيل المثال، عندما يتحقق موفر الهوية من صحة بيانات الاعتماد عن طريق الاتصال بخدمة ويب.
لا يزال تدفق الترحيل السلس يتطلب ما قبل الترحيل لحسابات المستخدمين، ولكنه يستخدم بعد ذلك نهج مخصص للاستعلام عن واجهة برمجة تطبيقات REST (التي تنشئها) لتعيين كلمة مرور كل مستخدم عند تسجيل الدخول الأول.
يتكون تدفق الترحيل السلس من مرحلتين: مرحلة ما قبل الترحيل وتعيين بيانات الاعتماد.
المرحلة 1: مرحلة ما قبل الترحيل
- يقرأ تطبيق الترحيل الخاص بك حسابات المستخدمين من موفر الهوية القديم.
- ينشئ تطبيق الترحيل حسابات المستخدمين المطابقة في دليل AAD (دليل Azure النشط) متاجرة عمل-مستهلك، ولكنه يعين كلمات مرور عشوائية تنشئها.
المرحلة 2: تعيين بيانات الاعتماد
بعد اكتمال مرحلة ما قبل ترحيل الحسابات، ينفذ بعدها نهجك المخصص وواجهة برمجة تطبيقات REST التالي عندما يسجل مستخدم ما دخوله:
- قراءة حساب المستخدم في AAD (دليل Azure النشط) متاجرة عمل-مستهلك المطابق لعنوان البريد الإلكتروني المُدخل.
- التحقق مما إذا كان قد وُضعت علامة على الحساب للترحيل عن طريق تقييم سمة ملحق منطقية.
- إذا أرجعت سمة الملحق
True، فاتصل بواجهة برمجة تطبيقات REST للتحقق من صحة كلمة المرور بالمقارنة مع موفر الهوية القديم.- إذا حددت واجهة برمجة تطبيقات REST أن كلمة المرور غير صحيحة، يتم إرجاع خطأ ودي للمستخدم.
- إذا حددت واجهة برمجة تطبيقات REST أن كلمة المرور صحيحة، فاكتب كلمة المرور في حساب AAD (دليل Azure النشط) متاجرة عمل-مستهلك وغير سمة الملحق المنطقية إلى
False.
- إذا أرجعت سمة الملحق المنطقية
False، فأكمل عملية تسجيل الدخول كالمعتاد.
- إذا أرجعت سمة الملحق
لمشاهدة مثال على نهج مخصص وواجهة برمجة تطبيقات REST، راجع عينة الترحيل السلس للمستخدم على GitHub.
الأمان
يستخدم نهج الترحيل السلس واجهة برمجة تطبيقات REST المخصصة الخاصة بك للتحقق من صحة بيانات اعتماد المستخدم بالمقارنة مع موفر الهوية القديم.
يجب حماية واجهة برمجة تطبيقات REST الخاص بك من هجمات القوة العمياء. يمكن للمهاجم إرسال العديد من كلمات المرور على أمل تخمين بيانات اعتماد المستخدم في نهاية المطاف. للمساعدة في هزيمة هذا النوع من الهجمات، توقف عن تقديم الطلبات إلى واجهة برمجة تطبيقات REST عندما يتخطى عدد محاولات تسجيل الدخول حداً معيناً. أيضاً، قم بتأمين الاتصال بين AAD (دليل Azure النشط) متاجرة عمل-مستهلك وواجهة برمجة تطبيقات REST الخاص بك. لمعرفة كيفية تأمين واجهات برمجة التطبيقات RESTful للإنتاج، راجع تأمين واجهة برمجة التطبيقات RESTful الخاصة بك.
سمات المستخدم
لا ينبغي ترحيل جميع المعلومات في موفر الهوية القديم إلى دليل AAD (دليل Azure النشط) متاجرة عمل-مستهلك الخاص بك. حدد المجموعة المناسبة من سمات المستخدم لتخزينها في AAD (دليل Azure النشط) متاجرة عمل-مستهلك قبل الترحيل.
-
مخزن DO في Azure AD B2C:
- اسم المستخدم، وكلمة المرور، وعناوين البريد الإلكتروني، وأرقام الهواتف، وأرقام/معرفات العضوية.
- علامات الموافقة على سياسة الخصوصية واتفاقيات ترخيص المستخدم النهائي.
-
لا تخزن في Azure AD B2C:
- البيانات الحساسة مثل أرقام بطاقات الائتمان، أو أرقام التأمين الاجتماعي (SSN)، أو السجلات الطبية، أو البيانات الأخرى التي تنظمها هيئات الامتثال الحكومية أو الصناعية.
- تفضيلات التسويق أو الاتصال، وسلوكيات المستخدم ونتائج التحليلات.
تنظيف الدليل
قبل بدء عملية الترحيل، انتهز الفرصة لتنظف الدليل.
- حدد مجموعة سمات المستخدم التي سيتم تخزينها في AAD (دليل Azure النشط) متاجرة عمل-مستهلك، ثم قم بترحيل ما تحتاج إليه فقط. إذا لزم الأمر، يمكنك إنشاء سمات مخصصة لتخزين المزيد من البيانات حول مستخدم.
- إذا كنت تقوم بترحيل من بيئة ذات مصادر مصادقة متعددة (على سبيل المثال، لكل تطبيق دليل المستخدم الخاص به)، فقم بالترحيل إلى حساب موحد في AAD (دليل Azure النشط) متاجرة عمل-مستهلك.
- إذا كان لدى العديد من التطبيقات أسماء مستخدمين مختلفة، يمكنك تخزينها كلها في حساب مستخدم AAD (دليل Azure النشط) متاجرة عمل-مستهلك باستخدام مجموعة الهويات. أما كلمة المرور، فدع المستخدم يختر كلمة مرور ثم عينها في الدليل. على سبيل المثال، مع الترحيل السلس، يجب تخزين كلمة المرور المختارة فقط في حساب AAD (دليل Azure النشط) متاجرة عمل-مستهلك.
- أزل حسابات المستخدمين غير المستخدمة، أو لا تقُم بترحيل حسابات قديمة.
سياسة كلمة المرور
إذا كانت قوة كلمة مرور الحسابات التي يجري ترحيلها أضعف من قوة كلمة المرور القوية التي يفرضها AAD (دليل Azure النشط) متاجرة عمل-مستهلك، فيمكنك تعطيل متطلبات كلمة المرور القوية. لمزيد من المعلومات، راجع خاصية نهج كلمة المرور.
الخطوات التالية
azure-ad-b2c/user-migration يحتوي المستودع على GitHub على مثال نهج مخصص للترحيل السلس ونموذج التعليمات البرمجية لواجهة برمجة تطبيقات REST:
نهج مخصص لترحيل المستخدم السلس ونموذج التعليمات البرمجية لواجهة برمجة تطبيقات REST