بالإجابة على السؤال في المنشور رقم 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. هذا هو نفس القيد لكن بشكل مختلف.
يمكننا تقديم مزيد من المعلومات إذا لزم الأمر، أو اختبار التطبيقات إذا كان ذلك مفيدًا.