إلغاء تجزئة عمليات تسجيل الدخول على جميع النطاقات

Eiji Kitamura

غالبًا ما تمتدّ تصاميم المؤسسات الحديثة لتشمل نطاقات متعدّدة ومختلفة. تحتفظ المؤسسات ببيئات مخصّصة لميزات مختلفة، مثل brand.example للتسويق وservice-app.example للمنتج الأساسي وsupport-portal.example لخدمة العملاء. من المفترض أن تقدّم تجربة موحّدة لتسجيل الدخول لجميع المستخدمين أثناء تنقّلهم بين هذه المواقع. ومع ذلك، غالبًا ما تدمج فِرق الهندسة هذه المجالات باستخدام تقنيات مخصّصة تؤدي إلى التجزئة. يؤدي ذلك إلى تعطيل إدارة بيانات الاعتماد المضمّنة في المتصفّح من خلال إيقاف عمليات الملء التلقائي في مدير كلمات المرور وتأخير اعتماد مفاتيح المرور.

إذا كان الحساب نفسه يمتد إلى نطاقات متعددة، يجب أن يدرك المستخدم أنّ النطاقات تنتمي إلى المؤسسة نفسها وأن يقدّم بيانات الاعتماد نفسها عند تسجيل الدخول. في أسوأ الحالات، ينشئ المستخدم حسابًا مكررًا أو يقدّم كلمة المرور إلى موقع إلكتروني للتصيّد الاحتيالي.

تعرَّف على كيفية استخدام المعايير والحلول المعمارية (مثل البيانات الوصفية وإطارات iframe من مصادر متعددة واتحاد الهوية وتوحيد النطاقات الفرعية) لحلّ مشكلة تجزئة الهوية على مستوى النطاقات المختلفة وتقديم تجربة سلسة للمستخدم.

الحلول الشائعة

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

طلبات استرجاع CORS

عندما تعمل النطاقات بشكل مستقل، تعتمد واجهات المستخدم بشكل متكرر على طلبات fetch()متعدّدة المصادر موجّهة إلى واجهة برمجة تطبيقات مركزية للمصادقة، ويمكن السماح بها بشكل آمن باستخدام مشاركة الموارد المتعدّدة المصادر (CORS). بما أنّ المتصفّحات غالبًا ما تحظر ملفات تعريف الارتباط على مستوى المواقع الإلكترونية أو تقيّدها، قد يصمّم المطوّرون واجهات برمجة التطبيقات هذه بشكل صريح لعرض رموز مميّزة للمصادقة، مثل JSON Web Tokens (JWT) ضمن حمولات JSON بدلاً من الاعتماد على عناوين Set-Cookie.

مشاركة قاعدة بيانات الحساب

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

مشاكل في عمليات تسجيل الدخول غير المتسقة

على الرغم من أنّ الحلول الفنية البديلة قد تحقق الوظائف الأساسية، إلا أنّها لا توفّر تجربة سلسة. تتسبّب عمليات تسجيل الدخول غير المتّسقة في حدوث مشاكل تؤثّر سلبًا في سهولة الاستخدام والأمان.

تجزئة خدمات إدارة كلمات المرور

أكبر عائق هو تعطُّل خدمات إدارة كلمات المرور. تربط أدوات إدارة كلمات المرور بيانات الاعتماد المخزَّنة بالمصدر المحدّد الذي تم تسجيلها فيه. ويمنع ذلك المتصفّح من تقديم ميزة "الملء التلقائي" على مستوى نطاقات مختلفة، حتى عندما تكون تابعة للمؤسسة نفسها.

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

وبما أنّ خدمة "مدير كلمات المرور" لا يمكن الاعتماد عليها في هذه المواقع، قد يتوقف المستخدمون عن استخدام الأدوات المتاحة لهذه المواقع. بدلاً من ذلك، غالبًا ما ينشئون كلمات مرور ضعيفة وسهلة التذكّر لإعادة استخدامها في مكان آخر، ما يؤدي إلى تدهور مستوى الأمان العام لمؤسستك.

بوابة التصيّد الاحتيالي

يعمل هذا التعطيل كبوابة تصيّد احتيالي. ويُعدّ رفض خدمة "مدير كلمات المرور" ملء الحقول تلقائيًا على نطاق غير معروف آلية دفاع أساسية. من خلال مطالبة المستخدمين بإدخال بيانات الاعتماد يدويًا على عناوين URL مختلفة، فإنّك تدربهم عن غير قصد على الوقوع ضحية لهجمات التصيّد الاحتيالي.

مشكلة مفتاح المرور

تتزايد الصعوبة عند استخدام مفاتيح المرور. تربط بنية الأمان الأساسية في WebAuthn مفاتيح المرور بشكل مشفّر بمعرّف الجهة المعتمِدة (RP ID) محدّد.

يؤدي ذلك إلى إنشاء "فخ معرّف RP". لا يمكن استخدام مفتاح مرور مسجَّل على brand.example على service-app.example لأنّ المتصفّح يرفض الوصول إلى نطاقات متعددة. لتجنُّب مطالبة المستخدمين بتسجيل مفاتيح مرور مختلفة لكل موقع إلكتروني، عليك دمج هذه المواقع في معرّف RP واحد.

الطُرق المقترَحة

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

• استخدام ملفات إعداد البيانات الوصفية: يمكنك استضافة ملفات البيانات الوصفية، مثل الروابط التي تنقل إلى مواد عرض رقمية وطلبات المصدر ذي الصلة، لإنشاء سلسلة ثقة مشفّرة. يتيح ذلك مشاركة بيانات الاعتماد ومفاتيح المرور بسلاسة على مستوى النطاقات المختلفة وتطبيقات الأجهزة الجوّالة. هذا الأسلوب هو حلّ منخفض التكلفة وغير مزعج لتجزئة الهوية، ولا يتطلّب إعادة تصميم معقّدة للبنية الأساسية الحالية على الويب.
• استخدام إطارات iframe مشتركة المصدر: يمكنك تضمين مصدر مصادقة مركزي كإطار iframe ضمن جهة معتمدة لربط بيانات الاعتماد المحفوظة ومفاتيح المرور على مواقع إلكترونية مختلفة. يستخدم هذا الأسلوب سياسة الأذونات وملفات تعريف الارتباط المجزّأة لتوفير تجربة تسجيل دخول سلسة ومناسبة للسياق مع الحفاظ على حدود أمان صارمة من خلال سياسة أمان المحتوى والمراسلة بين المستندات.
• اتّباع اتحاد الهوية العادي: استخدام بروتوكولات متوافقة مع المعايير المتّبعة في المجال، مثل OpenID Connect، لتنفيذ المصادقة بشكل مركزي على نطاق موفِّر هوية مخصّص يضفي ذلك طابعًا رسميًا على رحلة تسجيل الدخول من خلال عمليات إعادة توجيه آمنة، ما يتيح استبدال عمليات الدمج غير المستقرة بحلّ موثوق وقابل للتوسّع من الطرف الأول.
• توحيد النطاقات الفرعية: الانتقال إلى نطاقات فرعية ضمن نطاق رئيسي مشترك يتيح ذلك مشاركة الجلسة بسلاسة من خلال ملفات تعريف الارتباط ذات الأحرف البَديلة واستمرار مفتاح المرور على مستوى النطاق القابل للتسجيل بأكمله. يمكن للعديد من خدمات إدارة كلمات المرور التعرّف على النطاق الجذر المشترَك واقتراح بيانات الاعتماد المحفوظة تلقائيًا على مستوى النطاقات الفرعية ذات الصلة.

استخدام ملفات إعداد البيانات الوصفية

من التحديات الأساسية التي تواجه الهوية على مستوى عدة نطاقات هو تجزئة بيانات الاعتماد المحفوظة. تتعامل خدمات إدارة كلمات المرور مع النطاقات والتطبيقات المختلفة على أنّها كيانات منفصلة تمامًا، ما يمنعها من ملء بيانات الاعتماد المحفوظة في أحد المواقع أو التطبيقات تلقائيًا في موقع أو تطبيق آخر.

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

استخدِم ملفَي إعداد مختلفَين للتأكّد من تغطية المنصات والأنظمة الأساسية المختلفة:

• إدارة كلمات المرور من Google على Android وChrome: استضافة ملف JSON لروابط التنقّل إلى مواد العرض الرقمية (DAL) على /.well-known/assetlinks.json لإنشاء علاقة ثقة يمكن التحقّق منها بين التطبيقات والمواقع الإلكترونية المرتبطة بمؤسسة تتيح هذه الثقة استخدام الروابط لصفحات في التطبيقات وميزة "مشاركة بيانات الاعتماد بسلاسة"، حيث يتم تلقائيًا ملء المواقع الإلكترونية المرتبطة بكلمات المرور المحفوظة على الويب (مع ذلك، تتطلّب مشاركة مفاتيح المرور على مستوى نطاقات ويب متعددة استخدام طلبات المصدر المرتبط). يمكنك الاطّلاع على مزيد من المعلومات في دليل مشاركة بيانات الاعتماد بسلاسة.

• كلمات مرور Apple على iOS وSafari: استضافة ملف Apple App Site Association (AASA) على /.well-known/apple-app-site-association لإنشاء سلسلة الثقة المشفرة اللازمة لربط حالات كلمات مرور Apple على تطبيقات iOS ومتصفّح Safari لإتاحة استخدام أنظمة بيئية تابعة لجهات خارجية، يمكنك الإفصاح عن النطاقات المرتبطة هذه بشكل مركزي باستخدام مستودع مستند إلى المصادر الجماعية. ويضمن ذلك أن تتعرّف الأدوات المستقلة (مثل 1Password التي تستخدم هذا المستودع بشكل صريح) أيضًا على سياق الهوية المشتركة. لمزيد من المعلومات حول ميزة "ربط التطبيق بالموقع الإلكتروني" من Apple، يُرجى الاطّلاع على مقالة إتاحة النطاقات المرتبطة.

لإتاحة استخدام مفاتيح المرور على نطاقات ويب مختلفة وتخطّي مشكلة حظر مفاتيح المرور، يمكن للمطوّرين استضافة ملف طلبات الأصل المرتبط (ROR) على /.well-known/webauthn. توضّح ميزة "التسجيل بدون كلمة مرور" النطاقات المصرّح بها التي يُسمح لها بمشاركة معرّف RP نفسه الخاص بمفتاح المرور بشكل آمن. لمزيد من المعلومات حول طلبات المصدر ذات الصلة، يمكنك الاطّلاع على مقالة السماح بإعادة استخدام مفتاح المرور على مواقعك الإلكترونية من خلال طلبات المصدر ذات الصلة.

• الإيجابيات:
  • إصلاح في الخلفية للمستخدمين النهائيين: تعمل هذه الميزة بالكامل في الخلفية، ما يؤدي تلقائيًا إلى حلّ مشكلة تجزئة الملء التلقائي وتوفير استمرارية مفتاح المرور على مستوى نظام التشغيل أو المتصفّح بدون أي تغييرات مرئية في تجربة المستخدم.
  • التنفيذ البسيط: هذا الحلّ منخفض التكلفة، ولا يتطلّب سوى استضافة ملفات JSON ثابتة. ولا تتطلّب إعادة تصميم البنية الأساسية أو منطقًا معقّدًا لتبادل الرموز المميّزة.
  • الحفاظ على البنية الأساسية الحالية: يمكنك تحسين رحلة المستخدم على مستوى النطاقات بشكل كبير بدون تغيير علامتك التجارية أو دمج نطاقاتك.
• السلبيات:
  • قيود المنصّة: تفرض المنصّات عادةً حدودًا صارمة على عائد الإنفاق الإعلاني. على سبيل المثال، يحصر Chrome رقم تعريف RP واحدًا بـ 5 تصنيفات eTLD+1 مرتبطة كحدّ أقصى. على سبيل المثال، تتشارك example.co.uk وexample.de في تصنيف example نفسه الخاص بـ eTLD+1، ولكن example-rewards.com تستخدم تصنيف example-rewards منفصلاً. إذا كنت تدير مجموعة كبيرة أو متنوعة من النطاقات، قد لا تكون هذه الحدود كافية.
  • زيادة وقت الاستجابة التشغيلي: يتطلّب حلّ مشاكل ملفات البيانات الوصفية إجراء رحلة إضافية عبر الشبكة، ما يؤدي إلى زيادة وقت الاستجابة عندما يعالج المتصفّح عملية المصادقة.

استخدام إطارات iframe متعددة المصادر

إذا تعذّر عليك استخدام ملفات إعدادات البيانات الوصفية بسبب حدود نطاق ROR، توفّر عناصر iframe من مصادر متعددة مسارًا قويًا ومتوافقًا مع المعايير لحلّ مشاكل تسجيل الدخول على نطاقات متعددة.

من خلال تضمين مصدر مصادقة مركزي (على سبيل المثال، auth.brand.example) كإطار iframe ضمن جهة معتمدة (على سبيل المثال، brand.example)، يمكنك التفاعل مع كل من حقول النماذج العادية وواجهات برمجة التطبيقات الحديثة. بالنسبة إلى كلمات المرور، يربط مدير بيانات الاعتماد في المتصفّح إجراءات الملء التلقائي بمصدر الإطار المتضمّن (auth.example)، ما يتيح للمستخدمين الوصول إلى بيانات الاعتماد المركزية بسلاسة على المواقع الإلكترونية المختلفة.

بالنسبة إلى مفاتيح المرور، يجب أن تمنح النافذة الرئيسية إذن الوصول إلى iframe باستخدام إطار عمل سياسة الأذونات، ما يتيح لـ iframe استدعاء WebAuthn للمصادقة على معرّف RP الخاص بمصدره. في كلتا الحالتين، تكون سياسة أمان المحتوى (CSP) مفيدة لحماية المستخدمين من الهجمات، مثل النقر المخادع وتنفيذ النصوص البرمجية على المواقع الإلكترونية. بعد نجاح المصادقة، يتم إنشاء الجلسة باستخدام ملف تعريف ارتباط مقسَّم، ويتم نقل الرمز المميّز بشكل آمن إلى النافذة الرئيسية باستخدام postMessage().

• الإيجابيات:
  • بيانات الاعتماد المركزية: تتجنّب تجزئة بيانات الاعتماد. يدير مصدر مركزي واحد كلاً من كلمات المرور المحفوظة ومعرّف الطرف المعتمِد (RP ID) الموحّد الخاص بمفتاح المرور، ما يتيح للنطاقات المختلفة مشاركة بيانات الاعتماد هذه بدون الحاجة إلى دمج النطاقات.
  • المصادقة السياقية: تتم عملية تسجيل الدخول بأكملها بسلاسة في السياق ضمن الصفحة الرئيسية، سواء كان ذلك من خلال الملء التلقائي لكلمة المرور أو إثبات الهوية باستخدام مفتاح مرور، ما يمنع عمليات إعادة التوجيه المزعجة إلى نظام موحّد.
  • التوافق مع إجراءات الحماية من التتبُّع: يعمل هذا النهج بشكل صحيح حتى في ظل إجراءات الحماية الصارمة من التتبُّع على مواقع إلكترونية متعددة باستخدام ملفات تعريف الارتباط المقسَّمة.
• السلبيات:
  • قيود التنفيذ: تتطلّب هذه البنية خبرة هندسية متخصّصة. يتطلّب ذلك استخدام سياسة أمان المحتوى (CSP) صارمة (frame-ancestors) لحصر التضمين على نطاقات رئيسية موثوق بها ومنع هجمات النقر، وإعداد سياسات أذونات HTTP لتفعيل WebAuthn API، واستخدام ميزة المراسلة الآمنة التي تم التحقّق من صحتها بين المستندات (postMessage()) للحدّ من هجمات انتحال المصدر وهجمات طلبات التزوير عبر المواقع. يمكنك الاطّلاع على أفضل الممارسات في مقالة مفاتيح المرور داخل إطارات iframe.

اتّباع عملية اتحاد موفّري الهويات العادية

يُعدّ استخدام نظام موحّد لتحديد الهوية، مثل OpenID Connect، طريقة فعّالة ومستدامة للحفاظ على نظام حسابك. يعمل هذا الأسلوب على إضفاء الطابع الرسمي على سير عمل المصادقة من خلال دمجه في نطاق واحد مخصّص لموفّر الهوية (IdP)، مثل auth.brand.example. باستخدام بروتوكول محدّد، تعيد التطبيقات توجيه المستخدمين إلى هذا المركز لإجراء المصادقة قبل تلقّي عملية نقل الرمز المميّز بشكل آمن لإكمال عملية تسجيل الدخول على النطاق المستهدف. على الرغم من أنّ الربط غالبًا ما يرتبط بعمليات تسجيل الدخول التابعة لجهات خارجية (مثل تسجيل الدخول باستخدام حساب Google)، إلا أنّ الربط العادي صالح تمامًا ويُستخدم على نطاق واسع كحلّ تابع للطرف الأول بدلاً من الحلول البديلة غير المستقرة.

• الإيجابيات:
  • لغة هندسية مشتركة: لا يحتاج المطوّرون إلى تعلُّم بروتوكول مخصّص أو الحفاظ عليه، بل يمكنهم الاعتماد على المعرفة المتوفّرة في المجال والمكتبات الشاملة. تتوفّر أيضًا حلول جاهزة.
  • موثوقية تم اختبارها ميدانيًا: إنّ البروتوكولات العادية مثبتة وآمنة وأقل عرضة للأعطال من عمليات التنفيذ المخصّصة.
  • قابلة للتوسيع بسهولة: إذا كانت المؤسسة بحاجة إلى ربطها بخدمة خارجية جديدة أو دمج عملية استحواذ لاحقًا، تكون البنية الأساسية لإدارة الهوية مجهّزة مسبقًا لتقديم بيانات الاعتماد.
  • تجربة مستخدم متّسقة: يتعرّف المستخدمون على صفحة موفِّر الهوية المركزية باعتبارها المصدر الموثوق للعلامة التجارية، ما يوضّح متى وأين تكون بيانات الاعتماد مطلوبة.
• السلبيات:
  • تكلفة التكامل العالية: يؤدي تطوير أو نقل البيانات إلى موفّر هوية مركزي إلى تكلفة تكامل عالية ويتطلب خبرة أمنية متخصصة. على المؤسسات الاستثمار في إعادة تصميم جميع التطبيقات المرتبطة بشكل آمن لتتوافق مع أنماط إعادة التوجيه الآمنة.
  • عمليات إعادة التوجيه المزعجة: يتطلّب مسار المصادقة إعادة توجيه المستخدمين من الموقع الإلكتروني الأصلي إلى صفحة مركزية خاصة بمقدّم خدمة الهوية، ما يمنع توفير تجربة سلسة لتسجيل الدخول في السياق.

دمج النطاقات الفرعية

هناك طريقة أخرى منظَّمة وهي توحيد جميع النطاقات من خلال نقل المواقع الرقمية المختلفة إلى نطاق جذر مشترك قابل للتسجيل (eTLD+1). ويستلزم ذلك تحويل النطاقات المنفصلة، مثل brand.example وservice-app.example، إلى نطاقات فرعية، مثل www.brand.example وservice.brand.example.

• الإيجابيات:
  • إدارة موحّدة لبيانات الاعتماد: يمكن لخدمات إدارة كلمات المرور التعرّف على النطاق الأساسي والتعامل مع جميع النطاقات الفرعية كإدخال واحد، ما يمنع ظهور طلبات مكرّرة وإدخال كلمات المرور يدويًا.
  • استمرارية مفتاح المرور: يمكن للمطوّرين تحديد نطاق معرّف الجهة الاعتمادية لمفتاح المرور بشكل أصلي ليشمل النطاق القابل للتسجيل، ما يؤدي إلى توسيع نطاق توفّر مفتاح المرور ليشمل جميع النطاقات الفرعية المرتبطة. في هذه الحالة، سيعمل معرّف RP بقيمة brand.example في كل من www.brand.example وservice.brand.example.
  • مشاركة الجلسة بسهولة: يتيح توحيد بنية النطاق مشاركة جلسة واحدة باستخدام ملفات تعريف الارتباط ذات الأحرف البَديلة (على سبيل المثال، تحديد نطاق ملف تعريف الارتباط على Domain=brand.example).
• السلبيات:
  • قيود العلامة التجارية ونقل البيانات: يمكن أن يفرض هذا الأسلوب قيودًا محتملة على العلامة التجارية إذا كانت مؤسستك تتطلّب نطاقات مميزة ذات مستوى أعلى. عملية نقل البيانات معقّدة وتتطلّب إدارة دقيقة لعمليات إعادة التوجيه عبر HTTP ومعالجة شاملة لإعدادات المشاركة القديمة بين المصادر.

الخاتمة

لتحقيق استمرارية الهوية، عليك الانتقال من عمليات الدمج المخصّصة لتسجيل الدخول إلى معايير المصادقة المعتمَدة. من خلال تقييم قيود النشاط التجاري مقارنةً بهذه الممارسات المعمول بها، مثل الاتحاد أو دمج النطاقات أو إطارات iframe أو البيانات الوصفية، يمكنك التخلص من المشاكل التي تواجه المستخدمين وتحسين المصادقة في جميع أنحاء منظومتك المتكاملة.

لمزيد من المعلومات حول المواضيع ذات الصلة، احرص على متابعة مدونتنا واستكشاف المزيد من المراجع في بوابة هوية Chrome.