هذا رائع، أفضل بكثير من إضافة oauth2، التي لم تعمل. لكن هذه تعمل (مع Keycloak).
ومع ذلك، فإن مصادر oidc المتعددة ستكون ميزة مرحب بها للغاية.
هذه فكرة مثيرة للاهتمام. هل يمكنك إخبارنا بالمزيد عن حالة الاستخدام الخاصة بك لشرح الفوائد، وإذا أمكن، ما هي مصادر تسجيل الدخول التي ترغب في استخدامها؟
بالإجابة على السؤال في المنشور رقم 2 أعلاه: استخدامنا المقترح، ومصادر تسجيل الدخول التي نحتاجها.
نحن ندير منتدى مجتمعيًا عامًا لمبادرة أوروبية للبحث العلمي، على استضافة Discourse مُدارة داخل الاتحاد الأوروبي.
نحتاج إلى تمكين مزوّدي OIDC اثنين في الوقت نفسه:
- EU Login، مزوّد الهوية التابع للجنة الأوروبية. يُستخدم من قبل موظفي اللجنة، وأصحاب المصلحة في السياسات، والمشاركين في المشاريع الممولة من الاتحاد الأوروبي. يعتمد على OIDC القياسية، وتقع وثيقة الاكتشاف الخاصة به في
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration. - EGI Check-in، وكيل هوية أكاديمية فيدرالي يعمل كواجهة للحسابات المؤسسية وORCID. يُستخدم عبر البنى التحتية للبحث العلمي في أوروبا. يعتمد أيضًا على OIDC القياسية.
لا يغطي أيٌّ من المزوّدين مستخدمي الآخر. يسجّل مسؤول السياسة دخوله عبر EU Login ولا يملك هوية بحثية مؤسسية. يسجّل الباحث دخوله عبر حساب جامعي أو عبر ORCID من خلال وكيلنا، ولا يملك حساب EU Login. تتكون مجتمعنا من كلا المجموعتين، لذا فإن اختيار مزوّد واحد يعني استبعاد نصف الأشخاص الذين صُمم المنتدى من أجلهم.
يتحدث كلا المزوّدين بلغة OIDC العادية، ويعمل أيٌّ منهما بشكل مستقل. ما يعيقنا هو أن إضافة discourse-openid-connect تعرض مساحة إعدادات واحدة غير مرقمة: openid_connect_client_id، بدلاً من openid_connect_1_client_id وopenid_connect_2_client_id. لا يمكن تكوين مزوّد OIDC واحد فقط لكل موقع.
نرغب في دعم أكثر من مزوّد واحد. الشكل الأكثر طبيعية سيكون مساحة إعدادات لكل مزوّد، إما إعدادات مرقمة أو قائمة يديرها المسؤول، حيث يملك كل مزوّد وثيقة اكتشاف خاصة به، وبيانات اعتماد العميل، والنطاق (scope)، وعنوان الزر.
توجد سابقة سابقة في Multiple openid-connect authentication providers من عام 2021، حيث كان الاحتياج هو عدة ممالك (Realms) من Keycloak. هذا هو نفس القيد لكن بشكل مختلف.
يمكننا تقديم مزيد من المعلومات إذا لزم الأمر، أو اختبار التطبيقات إذا كان ذلك مفيدًا.
إعجاب واحد (1)
إحدى الخيارات التي يمكنك تجربتها هي إعداد خدمة Authentik و"الاندماج" مع هذين المزودين. بهذه الطريقة، يمكنك توفير تسجيل الدخول الأحادي (SSO) الداخلي لفريقك، وتسجيل دخول سSO موكَّل للمستخدمين الخارجيين. قد يكون الأمر أكثر صعوبة بعض الشيء، بالنظر إلى الحاجة إلى استضافة نظام SSO خاص بك، لكنه قد يكون أسرع من تعديل إضافة OIDC، اعتمادًا على قدراتك.
ومع ذلك، ألاحظ إعدادات (مزود تسجيل الدخول المؤسسي) في كل مكان ضمن إعدادات Discourse، لذا سيكون من الجيد حقًا أن نتمكن من إضافة مزودنا الخاص. ربما من خلال إنشاء فرع (Fork) لإضافة OIDC وتغيير الأسماء؟
4 إعجابات
شكرًا على النصيحة. خدمة EGI Check-in هي بالفعل وكيل IdP يتيح استخدام العديد من مزودي الهوية (IdPs).
القيد الحالي هو أن سياسة EU Login لا تسمح باستخدام الوكيل. هم يريدون اتصالًا مباشرًا بالخدمة.
إعجاب واحد (1)
في هذه الحالة، إذا كان التطبيق الآخر يدعم Oauth2، يمكنك إعداده باستخدام https://meta.discourse.org/t/discourse-oauth2-basic/33879، بحيث تتمكن من الاحتفاظ بـ OIDC لخدمة EU EIDAS. كان هناك أيضًا إضافة (plugin) لـ SAML، ربما أصبحت غير مدعومة.
إعجابَين (2)
شكرًا على هذا الاقتراح. في الواقع، نحن حاليًا نستكشف استخدام Discourse OAuth2 Basic مع EGI Check-in.
أردت لفت انتباه المجتمع إلى هذه الحالة، لأن إمكانية دعم مزودي OIDC متعددين من شأنها أن تستفيد منها مؤسسات أكثر في المستقبل وتبسط الأمور.
لم تكن خيار SAML ضمن نطاق اهتمامنا، وقد يكون خيارًا ثالثًا يستحق النظر. لقد وجدت الإضافة التالية: GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub
إعجابَين (2)