Je viens de configurer une instance Discourse et d’y ajouter le plugin discourse-openid-connect, en reliant Keycloak en tant que fournisseur OIDC.
Après avoir suivi les 3 conditions mentionnées ici avec une mise à jour récente, je constate que l’authentification se fait via Keycloak. Cependant, si je suis déjà connecté, cliquer sur le bouton « Se connecter » me propose de « Créer un nouveau compte » avec des champs préremplis à partir des informations Keycloak de l’utilisateur.
Existe-t-il un moyen de passer cette étape supplémentaire pour l’utilisateur ? Ces champs sont déjà naturellement remplis par Keycloak, il ne devrait donc pas être nécessaire que l’utilisateur les modifie spécifiquement pour Discourse.
La création du compte devrait-elle être gérée implicitement, comme le fait Grafana ? Mon objectif est que chaque service proposé par la communauté offre cette expérience transparente, afin que le compte communautaire initial avec lequel l’utilisateur s’est inscrit soit le seul dont il ait à s’occuper.
Cela peut sembler illogique si l’on pense à des authentifications externes comme Google, Facebook, GitHub, etc. Un utilisateur peut enregistrer son compte communautaire via Keycloak en utilisant l’un de ces services, mais c’est Keycloak lui-même, utilisé uniquement en interne, qui est destiné à fonctionner avec tous les services individuels. Par conséquent, un consentement et une inscription implicites/automatisés sont souhaitables.
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.
