I’ve just setup a Discourse instance and added the discourse-openid-connect to it, connecting Keycloak as the OIDC provider.
After following the 3 conditions stated here with a recent update, I get the behaviour to authenticate via Keycloak, or if already logged in, clicking the “Login” button will prompt me to “Create New Account” with the fields filled in sourced from Keycloak info on the user.
Is there a way to skip this part requiring an additional step from the user? These are fields are naturally already populated from Keycloak, so there shouldn’t be a need for the user to modify them specifically for Discourse.
The account creation should be handled implicitly, similar to how Grafana is able to do it? I am aiming for each service provided by the community to support this seamless experience, that the original community account that is signed-up is all they have to deal with.
This might not make sense if you’re thinking about external auth such as Google / Facebook / Github / etc. A user can register their community account via Keycloak with one of those, but Keycloak itself which is only used internally is what is intended to work with all the individual services, so implicit/automated consent and sign-up is desirable.
Nuevo en Discourse, tengo configurado y funcionando mi proveedor SSO OAuth2. Los nuevos usuarios ven el mensaje la primera vez que llegan y se autentican en Discourse. ¿Cómo puedo agilizar este proceso y hacer que el usuario se cree automáticamente? Los valores mostrados en esa pantalla son correctos y ocurren solo una vez. ¿Qué puedo hacer para eliminar esa pantalla y agilizar el proceso de creación de cuentas para los usuarios de mi comunidad?
Esto no es posible actualmente. Cuando los usuarios crean una cuenta por primera vez, deberán hacer clic en el botón “Crear nueva cuenta” en el formulario de registro.
El comportamiento que buscas es similar al de la implementación de SSO de Discourse. En ese caso, las cuentas se crean en segundo plano sin que el usuario rellene el formulario de registro. Parece que debería ser posible implementar una funcionalidad similar para los inicios de sesión con OAuth2, aunque es posible que haya casos en los que no se transmita suficiente información desde el proveedor de OAuth2 para crear una cuenta.
No he dedicado mucho tiempo a esto desde mi publicación aquí, pero finalmente opté por la función de SSO de Discourse utilizando un servicio de puente que encontré para OpenID-Connect. Era un servicio en Python con un contenedor Docker, lo que facilitó su despliegue con mi configuración de docker-compose.
Así que Keycloak proporcionaba la cuenta ya registrada y con sesión iniciada; al visitar Discourse, se registraba al usuario con los detalles proporcionados por el puente, si recuerdo bien. Ha pasado un tiempo desde que lo manejé, pero este fue un proceso ligeramente mejor que el soporte nativo de OAuth/OpenID-Connect de Discourse, según mi conocimiento (al menos en ese momento; no he verificado si se ha hecho algo para mejorarlo).
De cualquier forma, no se sincronizan los detalles de la cuenta como se espera. El usuario necesita cerrar sesión en Discourse y volver a iniciarla para que ocurra cualquier sincronización, e incluso entonces creo que había algunos elementos que no se podían sincronizar desde el proveedor de SSO a Discourse (grupos/roles, algo así, según recuerdo, tenía algunas complicaciones).
Creo que sería necesario detectar cuando se actualizan los detalles del usuario en el proveedor para desencadenar la actualización en Discourse a través de sus APIs y lograr una configuración de sincronización adecuada. De lo contrario, podrías tener detalles duplicados que no estén sincronizados, o una sincronización confusa para los usuarios.
Así que, eh, si la integración de SSO con OAuth2 que tienes actualmente no es la función de SSO de Discourse (que generalmente requiere un puente de SSO, según mi conocimiento), sino esa alternativa basada en un plugin, cambiar a la versión sin plugin junto con un puente de SSO debería ofrecerte la experiencia deseada, si recuerdo bien.
También me interesa evitar esta ventana de “Crear nueva cuenta” al usar OAuth2.
¿Quizás se pueda añadir una opción en algún lugar para omitirla si todos los campos están disponibles?
Acabo de agregar algunas nuevas configuraciones del sitio que ayudarán con esto. Para omitir la pantalla de ‘crear nueva cuenta’, habilita sso_overrides_username, sso_overrides_email y sso_overrides_name.
Luego, para omitir completamente la ventana emergente, habilita external_auth_skip_create_confirm.
Si no ves esa opción, asegúrate de estar en la versión más reciente de tests-passed.
Ya existe una cuenta creada con el nombre test__EMAIL__ en nuestro Discourse.
Si inicio sesión con OpenID y el nombre de usuario: test, correo: test__EMAIL__,
aparece una ventana de “Nueva cuenta” que me pide un nuevo nombre de usuario (test1) y el correo test__EMAIL__.
No hay forma de vincular la cuenta antigua con OpenID.
¿Verifica su proveedor de OpenID Connect los correos electrónicos de los usuarios? Solo podemos ‘confiar’ en el correo electrónico de OIDC si ha sido verificado y el valor booleano de verificado está establecido correctamente.
Sin proveedor OID - Keycloak con federación de usuarios LDAP
Encontramos la solución: el usuario antiguo puede conectar OpenID en la interfaz de configuración del usuario.
@david, tenemos la versión 2.5.2 estable; esta opción no aparece… ¿Se puede trasladar esta opción a la rama estable? La necesitamos, pero en producción solo usamos la rama estable…
Me temo que no, no hacemos backport de nuevas funciones a la rama estable. Mantente atento a #releases para obtener información sobre cuándo se lanzará la próxima versión estable.
