security - تسجيل الدخول عبر النطاق - كيفية تسجيل دخول المستخدم تلقائيًا عند نقله من نطاق إلى آخر




3 Answers

يعد الدخول الموحد (SSO) أمرًا بسيطًا من الناحية النظرية.

  • المستخدم يضرب domain1.com .
  • يرى موقع domain1.com أنه لا يوجد ملف تعريف ارتباط للجلسة.
  • يعيد domain1.com التوجيه إلى sso.com
  • تقدم sso.com صفحة تسجيل الدخول ، وتأخذ أوراق الاعتماد
  • sso.com يحدد ملفات تعريف الارتباط للجلسة للمستخدم
  • بعد ذلك يقوم sso.com بإعادة التوجيه إلى domain1 إلى عنوان url خاص (مثل domain1.com/ssologin )
  • يحتوي عنوان URL الخاص بـ ssologin على معلمة تم توقيعها بشكل أساسي بواسطة sso.com . يمكن أن تكون بسيطة مثل base64 من تشفير loginid باستخدام مفتاح سر مشترك.
  • يأخذ domain1.com الرمز المميز المشفّر ، ويفك تشفيره ، ويستخدم معرف تسجيل الدخول الجديد لتسجيل الدخول إلى المستخدم.
  • يعين domain1 ملف تعريف ارتباط جلسة العمل للمستخدم.

الآن ، القضية القادمة.

  • domain2.com المستخدم إلى domain2.com ، والذي يتبع sso.com ويعيد توجيهه إلى sso.com
  • sso.com لديها بالفعل ملف تعريف الارتباط للمستخدم ، لذلك لا يقدم صفحة تسجيل الدخول
  • إعادة توجيه sso.com مرة أخرى إلى domain2.com مع المعلومات المشفرة
  • سجلات domain2.com في المستخدم.

هذه هي أساسيات كيف يعمل هذا. يمكنك جعلها أكثر قوة ، وأكثر ثراء بالمميزات (على سبيل المثال ، هذا هو SSOn ، ولكن ليس SSOff ، يمكن للمستخدم "تسجيل الخروج" من domain1 ، ولكن لا يزال يتم تسجيل الدخول إلى domain2 ). يمكنك استخدام المفاتيح العامة لتوقيع بيانات الاعتماد ، ويمكنك الحصول على طلبات لنقل المزيد من المعلومات (مثل حقوق التفويض ، إلخ) من خادم SSO. يمكنك الحصول على تكامل أكثر حميمية ، مثل النطاقات التي تتحقق بشكل روتيني من أن المستخدم لا يزال يتمتع بحقوق من خادم SSO.

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

نحن نقدم عددًا من الخدمات عبر الإنترنت. نحن مطالبون بتطوير نظام يوفر تجربة سريعة / بسيطة للمستخدمين إذا تم نقلهم من خدمة واحدة (على domain1.com ) إلى خدمة أخرى (على domain2.com ).

هل هناك طريقة آمنة ومأمونة لتسجيل الدخول تلقائيًا للمستخدم بمجرد نقله إلى الخدمة الجديدة؟

صاح في وجهي إذا كان الحل أدناه غير آمن / خاطئ تمامًا.

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

سيقوم domain1.com بإنشاء تجزئة فريدة وتخزينها في قاعدة بيانات مع التجزئة المرتبطة مستخدم مع حقل تاريخ / وقت انتهاء الصلاحية.

سيتم نقل المستخدم إلى domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

domain2.com بعد ذلك طلبًا إلى domain1.com باستخدام التجزئة للحصول على معلومات حول المستخدم. domain1.com ثم إزالة التجزئة من قاعدة البيانات. سوف domain2.com تسجيل المستخدم في وتعيين ملف تعريف الارتباط إلخ.

هل يمكن أن يعتمد شيء ما على OpenID أو OAuth على النتائج نفسها؟




لن يكون هناك أي نقطة باستخدام SSL لتسجيل الدخول عبر النطاقات ما لم تستخدم طبقة المقابس الآمنة في الجلسة بأكملها. من السهل جدًا سرقة ملف تعريف ارتباط جلسة عمل لاستخدام تجزئة في عنوان url. ما الهدف من إخفاء التجزئة في طبقة المقابس الآمنة إذا كان باقي الجلسة غير آمن.

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




ماذا عن تحسين محركات البحث؟ يبدو مثل كل طلب قبل إعادة توجيه تسجيل الدخول بنجاح إلى نطاق آخر وإلى الخلف. أود أن أقول أن هذا قبيح جدا. ما الرؤوس التي يجب إرسالها؟ 301 إلى SSO ثم العودة 301 إلى الصفحة الأصلية؟ لذلك هو "البحث" بوت البحث لتغيير مؤشره لتلك الصفحة مرتين؟




Related