Respondiendo a la pregunta en la publicación #2 anterior: nuestro caso de uso y qué fuentes de inicio de sesión necesitamos.
Operamos un foro comunitario público para una iniciativa de investigación de la UE, alojado en un servicio de Discourse gestionado dentro de la UE.
Necesitamos habilitar dos proveedores de OIDC al mismo tiempo:
- EU Login, el proveedor de identidad de la Comisión Europea. Es utilizado por el personal de la Comisión, las partes interesadas en políticas y los participantes en proyectos financiados por la UE. Utiliza OIDC estándar, con su documento de descubrimiento en
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration. - EGI Check-in, un proxy de identidad académica federada que gestiona cuentas institucionales y ORCID. Se utiliza en toda la infraestructura de investigación europea. También es OIDC estándar.
Ninguno de los dos cubre a los usuarios del otro. Un funcionario de políticas inicia sesión con EU Login y no tiene una identidad de investigación institucional. Un investigador inicia sesión con una cuenta universitaria o con ORCID a través de nuestro proxy y no tiene EU Login. Nuestra comunidad está compuesta por ambos grupos, por lo que elegir un solo proveedor significa rechazar a la mitad de las personas para las que está destinado el foro.
Ambos proveedores utilizan OIDC ordinario, y cualquiera de ellos funciona por sí solo. Lo que nos impide avanzar es que discourse-openid-connect expone un único espacio de nombres de configuración sin numerar: openid_connect_client_id, en lugar de openid_connect_1_client_id y openid_connect_2_client_id. Solo se puede configurar un proveedor de OIDC por sitio.
Nos gustaría soporte para más de uno. La forma más natural sería un espacio de nombres de configuración por proveedor, ya sea configuraciones numeradas o una lista gestionada por el administrador, donde cada proveedor tenga su propio documento de descubrimiento, credenciales de cliente, alcance y título de botón.
Existe un antecedente anterior en Multiple openid-connect authentication providers de 2021, donde la necesidad era de varios reinos de Keycloak. Esa es la misma limitación en una forma diferente.
Podemos proporcionar más información si es necesario, o probar implementaciones si eso puede ayudar.