¿Provisionar cuentas automáticamente con proveedor SSO externo? (omitir el mensaje de Crear nueva cuenta)

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.

2 Me gusta

New to discourse, i’ve got my SSO OAUTH2 provider setup and working. New users are seeing the prompt the first time they arrive and authenticate to discourse. How can I streamline this process and have the user automatically created. The values populated in that screen are correct, and a one time thing. What can I do to eliminate that screen and streamline the account creation process for my community users?

This is not currently possible. When users first create an account, they will need to click the “Create New Account” button on the signup form.

The behaviour that you are looking for is similar to how Discourse’s implementation of SSO works. In that case, accounts are created in the background without the user filling in the signup form. It seems it should be possible to implement similar functionality for OAuth2 logins, but possibly there are cases where not enough information is passed from the OAuth2 provider to create an account.

1 me gusta

I haven’t put much time into this since my post here, but I did end up getting Discourse SSO feature instead to use a bridging service I came across for OpenID-Connect, it was a python service that had a docker container, that made deploying with my docker-compose setup easier.

So Keycloak provided the account already registered and signed-in, visiting Discourse would then sign-up the user with details provided from the bridge iirc. It’s been a while since I dealt with it, but this was a slightly better process than Discourse OAuth/OpenID-Connect support afaik(at least at the time, haven’t checked if anything has been done to improve it).

Either way, you don’t get account details sync’d as expected. The user needs to sign out of Discourse and back in for any sync to occur, and even then I think there were some things that could not be sync’d from the SSO provider to Discourse(groups/roles, something like that iirc had some gotchas).

You would need to detect the user details being updated from the provider to trigger updating Discourse via it’s APIs I think to get a proper sync setup. Otherwise you can have duplicated details that aren’t in sync, or confusing sync to the users.


So uhh, if the OAuth2 SSO integration you currently have is not the Discourse SSO feature that generally requires an SSO bridge afaik, but that plugin alternative, changing to the non-plugin version with an SSO bridge should get that desired experience you want iirc…

1 me gusta

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.

10 Me gusta

external_auth_skip_create_confirm está activado

Tenemos un problema:

  1. Ya existe una cuenta creada con el nombre test__EMAIL__ en nuestro Discourse.
  2. 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.

2 Me gusta

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.

1 me gusta

@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.

@david
No está del todo claro de qué trata la próxima versión estable… ¿La versión menor 2.5.3? ¿O la versión 2.6.0?

La próxima versión mayor será la 2.6.0. Las versiones menores (2.5.x) se lanzarán únicamente para correcciones de seguridad.

@david
¡Gracias! Ahora está claro. ¿Se lanzará la versión 2.6.0 este año o no? )))

No tenemos una fecha confirmada, pero sí, hay buenas probabilidades de que sea este año :slight_smile:

3 Me gusta