منذ التحديث من DiscourseSSO إلى DiscourseConnect، توقفت عملية تكامل SSO لدينا عن العمل.
لدينا إعداد ربما يكون غير مألوف، حيث توجد تطبيقات متعددة يمكن من خلالها بدء عملية SSO، بدلاً من تطبيق واحد فقط. يمكن تثبيت برنامجنا محليًا (on-prem) أو في سحابة متعددة المستأجرين. تتضمن كل نسخة مستأجرة من البرنامج رابط SSO متصل بمجتمع Discourse الخاص بنا. وهذا يعني أنه يمكننا بدء عملية SSO من (على سبيل المثال) tenant1.ourcompany.com ومن software.tenant2.com ومن something.else.com — أي من ما يقرب من ألف مكان مختلف.
لا نملك مزود هوية مركزي واحد عبر جميع المستأجرين؛ فكل مستأجر يمكنه استخدام حل IDP خاص به (Google، O365، AD، Okta، …). على مستوى الخادم، لدينا عمليات وتدابير تخفيفية موضوعة لحماية الحسابات من الاختراق.
للأسف، يبدو أن نهجنا هذا توقف عن العمل في أحدث تحديث لـ Discourse. (شكرًا على هذا الالتزام.) من منظور تقني، كانت العملية التي كانت تعمل كالتالي:
- كان الخلفي الخاص بنا يحصل عبر واجهة برمجة التطبيقات (API) على رمز غير متكرر (nonce) وتفاصيل SSO من Discourse
- كان Discourse يرسل إعادة توجيه 301 مع حمولة SSO إلينا إلى عنوان محدد واحد
- كان الخادم هنا مُهيأً لتجاهل إعادة التوجيه 301 (لتجنب أخطاء الرمز غير المتكرر). وبدلاً من ذلك، كان يقوم بتحليل رأس
Location، وفك تشفير قيم base64، واستخراج الرمز غير المتكرر، وتوليد حمولة SSO، وتوقيعها باستخدام سر SSO، ثم توجيه المستخدم إلى عنوان تسجيل الدخول عبر SSO.
يبدو أن الرمز غير المتكرر تم تغييره بحيث يكون مرتبطًا بجلسة المتصفح (لحماية هجمات CSRF). وهذا يعني أنه عند محاولة العملية المذكورة أعلاه، يكون متصفح العميل يفتقر إلى كوكيز _forum_session الخاصة بالرمز غير المتكرر عندما نعيده إلى Discourse، وبالتالي نحصل على رسالة “انتهى صلاحية الرمز غير المتكرر”.
هل من الممكن جعل حماية CSRF اختيارية؟ أي إضافة إعداد جديد باسم enable_secure_nonce يمكن ضبطه على false؟
في الوضع الحالي، معظم عملائنا محجوبون عن الدخول إلى المنتدى الخاص بنا، ونواجه الحاجة إلى إجبارهم جميعًا على إعداد كلمات مرور، وفقدان قدرتنا على تتبع إشعارات المنتدى داخل تطبيقنا — مما سيؤدي إلى انخفاض في المشاركة. 