كنت أحاول العثور على إضافة SSO تسمح لي بالاستفادة من المطالبات القادمة من موفر الهوية الخاص بي لمستخدمي Discourse.
في إضافة OIDC، أنت مقيد تقريبًا بنقطة نهاية userinfo. هذا ليس سيئًا، لكنني كنت أحاول استخدام معلومات أخرى من مخزن الهوية الخاص بنا ولا يمكن تعديل نتيجة userinfo. لقد حاولت إجبار إضافة OIDC على استخدام id_token_info لتصنيع المستخدم، ولكن لم ينجح الأمر.
عدت إلى إضافة oauth، ولكن على السطح تبدو أنها تحتوي على نفس القيد الأساسي وهو أنها تعتمد على معلومات المستخدم من نقطة نهاية محددة. أعمل لمعرفة ما إذا كان بإمكاني العثور على واحدة تعيد محتوى مطالبات JWT، ولكن هذا ليس حالة استخدام طبيعية حقًا لذا لا أتوقع الكثير.
في الأصل، اعتقدت أنه يمكن استخدام “مسارات معلومات المستخدم عند الاستدعاء” في oauth basic لربط المطالبات بالمستخدم، ولكن يبدو دائمًا أنني أحصل على قيم فارغة في الاستجابة وفشل الإدراج. يمكنني فك تشفير الرمز المميز من موفر الهوية ورؤية المطالبات الصحيحة وفي هذه الحالة في جذر JSON مثل iss و exp وما إلى ذلك، ولكن لا يمكنني ربطها بجانب ActiveRecord.
أنا أبحث في jwt ولكن يبدو أنها لا تحتوي على ربط المطالبات بالمستخدم على الإطلاق. بشكل أساسي، إذا حصلت على 200 فأنت بخير، وهو ليس ما كنت أبحث عنه أيضًا.
ما لم أكن غبيًا بشكل إضافي اليوم، فإنه يغطي فقط المصادقة بسمات ثابتة. لا توجد طريقة لتعيين مطالبة وجدتها. إذا كنت سأقوم بعمل نسخة من شيء ما، فمن المحتمل أن يكون هذا هو المكان الذي سأبدأ منه، لكنني أردت التأكد من أنني لا أفوت شيئًا واضحًا هناك.
ولإضافة المزيد من السياق لمن يجدون هذا الموضوع بالصدفة.
يبدو أن OAuth الأساسي يدعم فقط استخلاص السمات من نقطة نهاية بيانات مستخدم محددة ولا يدعم تعيين مطالبات JWT. لذا فهو مشابه لمكون OIDC الإضافي، ولكن بدلاً من موقع معلومات المستخدم المقدم من مستند الاكتشاف، يمكنك استهداف أي نقطة نهاية JSON ثم التعيين حسب المسار. إضافة الإعدادات لتضمين المصادقة في الرأس ويمكنك الوصول إلى أماكن مثل https://graph.microsoft.com/v1.0/me الذي نستخدمه للمصادقة المستندة إلى Entra.
الآن يوفر Entra ID بعض قابلية التوسع للكائنات الأساسية، ولكنه ليس سهلاً مثل إضافة مطالبة اختيارية وسيكون تغييرًا شاملاً بناءً على ما أراه. لذلك لست متأكدًا من أنه خيار حقيقي بالنسبة لنا. بالرجوع خطوة أخرى إلى مسار النضج والقيام بمكون JWT الإضافي فقط يبدو أنه المسار الوحيد، ولكنه سيتطلب بعض العمل في طلبات السحب لإضافة دعم تعيين المطالبات. بشكل أساسي بنفس الطريقة التي يسمح بها oauth2-basic الحالي بتخصيص تعيين حقل Discourse إلى سمة JSON، فإنه سيحتاج إلى السماح بمزيد من التخصيص للحقل إلى مطالبات JWT.
الآن هذا مسار لنا، لكنني واجهت مشكلة مختلفة أعتقد أنها توقف كل شيء.
بعد تشغيل oauth2-basic بنجاح، يطالب بإنشاء مستخدم جديد ويرى أن هناك مستخدمًا موجودًا يستخدم البريد الإلكتروني من استخدام مكون OIDC الإضافي الحالي. على الرغم من أنهم يشتركون في نفس سمة البريد الإلكتروني، أعتقد أنه لا يمكنه الانتقال بين الموفرين لنفس مستخدم Discourse. وجود الجميع يبدأ من الصفر ليس خيارًا حقيقيًا وبينما يمكنني على الأرجح تعديل سجل حساب مرتبط بـ OAuth من موفر OIDC، أشعر أنني أطلب المتاعب. لذلك حتى لو كان JWT لديه دعم تعيين المطالبات، فإن جميع المستخدمين الحاليين مرتبطون بموفر OIDC بدون بعض حيل قاعدة البيانات أو بناء معالج “مستخدم موجود” للسماح بتغيير الحساب المرتبط، يبدو أنك عالق.
كنت آمل أن يتم ربطهم إما بالسماح بسجل user_associated واحد لكل مستخدم Discourse (لكل provider_id) أو مطالبة “ربط” للسماح بالتبديل من موفر إلى موفر جديد. في اختباري لم يكن الأمر كذلك، ولكنه يلاحظ البريد الإلكتروني قيد الاستخدام ويطالب بإنشاء مستخدم جديد.
إذا كنت سأبقى مع نفس المكون الإضافي، فأنا متأكد من أنه سيكون سلسًا، ولكن في هذه الحالة، فهي معرفات موفر فريدة لكل منها بيانات وصفية خاصة بها.