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.
Nouveau sur Discourse, j’ai configuré et fait fonctionner mon fournisseur SSO OAuth2. Les nouveaux utilisateurs voient l’invite la première fois qu’ils arrivent et s’authentifient sur Discourse. Comment puis-je simplifier ce processus et faire en sorte que l’utilisateur soit créé automatiquement ? Les valeurs renseignées dans cet écran sont correctes et ne concernent qu’une seule fois. Que puis-je faire pour supprimer cet écran et simplifier le processus de création de compte pour les utilisateurs de ma communauté ?
Ce n’est pas actuellement possible. Lorsque les utilisateurs créent un compte pour la première fois, ils doivent cliquer sur le bouton « Créer un nouveau compte » dans le formulaire d’inscription.
Le comportement que vous recherchez est similaire au fonctionnement de l’implémentation de SSO de Discourse. Dans ce cas, les comptes sont créés en arrière-plan sans que l’utilisateur n’ait à remplir le formulaire d’inscription. Il semble possible d’implémenter une fonctionnalité similaire pour les connexions OAuth2, mais il se peut qu’il n’y ait pas suffisamment d’informations transmises par le fournisseur OAuth2 pour créer un compte dans certains cas.
Je n’ai pas beaucoup investi de temps là-dedans depuis mon message ici, mais j’ai fini par utiliser la fonctionnalité SSO de Discourse avec un service de pontage que j’ai découvert pour OpenID-Connect. C’était un service Python avec un conteneur Docker, ce qui a facilité le déploiement avec ma configuration docker-compose.
Ainsi, Keycloak fournissait déjà le compte enregistré et connecté ; en visitant Discourse, l’utilisateur était ensuite inscrit avec les détails fournis par le pont, si ma mémoire est bonne. Cela fait un moment que je n’ai plus traité cela, mais c’était un processus légèrement meilleur que le support OAuth/OpenID-Connect de Discourse, à ma connaissance (du moins à l’époque, je n’ai pas vérifié si des améliorations ont été apportées depuis).
Quoi qu’il en soit, vous n’obtenez pas la synchronisation des détails du compte comme prévu. L’utilisateur doit se déconnecter de Discourse et se reconnecter pour que toute synchronisation ait lieu, et même dans ce cas, je pense qu’il y avait certaines choses qui ne pouvaient pas être synchronisées du fournisseur SSO vers Discourse (groupes/rôles, quelque chose comme ça, il y avait des pièges, si ma mémoire est bonne).
Je pense qu’il faudrait détecter les mises à jour des détails de l’utilisateur provenant du fournisseur pour déclencher la mise à jour de Discourse via ses API afin d’obtenir une configuration de synchronisation correcte. Sinon, vous pouvez avoir des détails dupliqués qui ne sont pas synchronisés, ou une synchronisation confuse pour les utilisateurs.
Donc euh, si l’intégration SSO OAuth2 que vous avez actuellement n’est pas la fonctionnalité SSO de Discourse qui nécessite généralement un pont SSO, à ma connaissance, mais plutôt cette alternative sous forme de plugin, passer à la version non-plugin avec un pont SSO devrait vous offrir l’expérience souhaitée, si ma mémoire est bonne.
Je suis également intéressé par l’évitement de cette fenêtre « Créer un nouveau compte » lors de l’utilisation d’OAuth2.
Peut-être qu’une option pourrait être ajoutée quelque part pour la sauter si tous les champs sont disponibles ?
Je viens d’ajouter de nouveaux paramètres de site qui devraient aider à résoudre ce problème. Pour contourner l’écran « Créer un nouveau compte », activez sso_overrides_username, sso_overrides_email et sso_overrides_name.
Ensuite, pour éviter complètement l’apparition de la fenêtre contextuelle, activez external_auth_skip_create_confirm.
Si vous ne voyez pas cette option, assurez-vous d’utiliser la dernière version de tests-passed.
Un compte test__EMAIL__ existe déjà dans notre Discourse.
Si je me connecte avec OpenID en utilisant le nom d’utilisateur : test et l’email : test__EMAIL__,
une fenêtre « Nouveau compte » s’ouvre et me demande un nouveau nom d’utilisateur (test1) et l’email test__EMAIL__.
Il n’existe aucun moyen de lier l’ancien compte à OpenID.
Votre fournisseur OpenID Connect vérifie-t-il les adresses e-mail des utilisateurs ? Nous ne pouvons « faire confiance » à l’e-mail provenant d’OIDC que s’il a été vérifié et que le booléen vérifié est correctement défini.
Aucun fournisseur OID - Keycloak avec fédération d’utilisateurs LDAP
Nous avons trouvé la solution : un ancien utilisateur peut se connecter via OpenID dans l’interface des paramètres utilisateur.
@david, nous avons la version 2.5.2 stable — cette option est absente… Peut-on migrer cette option vers la branche stable ? Nous en avons besoin, mais nous n’utilisons rien en production sauf la branche stable…
Je crains que non, nous ne rétroportons pas les nouvelles fonctionnalités vers la branche stable. Surveillez #releases pour des informations sur la date de sortie de la prochaine version stable.
