Esto es genial, mucho mejor que el plugin oauth2, que no funcionaba. Pero este sí funciona (con Keycloak).
Sin embargo, múltiples fuentes oidc serían una característica muy bienvenida.
Esa es una idea interesante. ¿Puede contarnos más sobre su caso de uso para explicar los beneficios y, si es posible, qué fuentes de inicio de sesión le gustaría utilizar?
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.
1 me gusta
Una opción que podrías probar es configurar un servicio de Authentik y “federar” con estos dos proveedores. De esta manera, podrías tener SSO interno para tu equipo y SSO proxy para usuarios externos. Sería un poco más difícil, dado que habría que alojar tu propio SSO, pero quizás sería más rápido que parchear el plugin de OIDC, dependiendo de tu capacidad.
Dicho esto, veo configuraciones de (Proveedor de inicio de sesión corporativo) por todas partes en las configuraciones de Discourse, así que sería realmente agradable poder añadir las nuestras. ¿Quizás hacer un fork del plugin de OIDC y cambiar los nombres?
4 Me gusta
Gracias por el consejo. El servicio EGI Check-in ya es un proxy de IdP que permite el uso de muchos IdP.
La restricción actual es que la política de EU Login no permite el uso de un proxy. Quieren una conexión directa con el servicio.
1 me gusta
En ese caso, si el otro puede usar OAuth2, puedes configurarlo con Discourse OAuth2 Basic, de modo que puedas mantener OIDC para la EU EIDAS. Antes existía un plugin de SAML, pero es posible que haya sido descontinuado.
2 Me gusta
Gracias por la sugerencia. Efectivamente, actualmente estamos explorando el uso de Discourse OAuth2 Basic con EGI Check-in.
Quería poner este caso en conocimiento de la comunidad, ya que la posibilidad de admitir múltiples proveedores de OIDC probablemente beneficiará a más organizaciones en el futuro y facilitará las cosas.
La opción SAML no estaba en nuestro radar; podría ser una tercera opción a considerar. He encontrado el plugin: GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub
2 Me gusta