Si vous avez toujours souhaité utiliser Discourse comme fournisseur d’authentification, c’est désormais possible !
Au cours de la dernière semaine, j’ai développé un petit service pouvant servir de fournisseur OpenID Connect/OAuth avec Discourse en tant que backend.
Vous pouvez consulter le code ici :
Notez que mon cas d’utilisation principal était l’authentification sur Nextcloud via Discourse, il se peut donc que cela ne fonctionne pas pour votre cas d’utilisation spécifique.
Si quelque chose ne fonctionne pas comme prévu, ou s’il manque cette fonctionnalité précise pour que cela fonctionne pour vous, n’hésitez pas à ouvrir une issue dans le dépôt GitHub.
Super initiative ! J’ai toujours voulu que Discourse puisse être utilisé comme fournisseur OAuth, afin de pouvoir l’intégrer facilement à davantage d’outils. En faire un petit service externe est également très logique !
J’apprécie l’idée et j’espère que certaines communautés décideront de l’essayer !
J’aimerais beaucoup voir OIDC pris en charge officiellement par Discourse, en plus de notre fonctionnalité personnalisée Discourse Connect, afin que nous puissions offrir une solution clé en main à nos clients sur les offres Standard et Teams, sans avoir à dépendre d’Okta ou d’autres solutions similaires.
La méfiance est un service distinct, vous devez donc le déployer en tant que tel. Vous pouvez l’exécuter dans un conteneur comme décrit dans le fichier README. Notez que pour un fonctionnement sécurisé, vous aurez également besoin d’un proxy inverse gérant la terminaison SSL (je pourrais l’implémenter directement à un moment donné dans le futur).
J’espère avoir quelques avis d’experts sur les problèmes que je rencontre en essayant d’utiliser Discourse comme fournisseur SSO.
Mon objectif : Je configure Discourse pour gérer l’authentification d’une autre application (LibreChat). J’utilise la fonctionnalité standard du fournisseur DiscourseConnect, avec le service de pont OIDC distrust agissant comme client qui communique avec Discourse.
Le problème : Le flux SSO fonctionne parfaitement jusqu’à la toute dernière étape. L’utilisateur est correctement redirigé de mon application vers Discourse, et il peut se connecter avec succès à ses identifiants Discourse. Cependant, après la connexion, il est redirigé vers la page d’accueil de mon forum Discourse (/) au lieu de l’return_sso_url qui avait été fournie.
Là où je bloque (Ce que j’ai écarté) : J’ai passé beaucoup de temps à résoudre ce problème et j’ai confirmé qu’il ne s’agissait pas d’une simple erreur de configuration. J’ai définitivement écarté les points suivants :
Secrets : Les secrets du fournisseur Discourse Connect sont correctement configurés. J’utilise le domaine brut (par exemple, auth.my-site.com) sans aucun protocole, et la clé secrète correspond parfaitement à celle de mon service client.
Mode SSO : J’ai vérifié que activer le fournisseur Discourse Connect est coché, et que les paramètres incorrects de « Client SSO » sont désactivés.
Politiques utilisateur : Je me suis assuré que must_approve_users est désactivé, et que mon utilisateur de test est un administrateur avec un e-mail entièrement vérifié.
Plugins : J’ai désactivé tous les plugins tiers non officiels et reconstruit le conteneur, mais le problème persiste.
Les preuves clés : J’ai deux preuves définitives qui me laissent perplexe :
Analyse du fichier HAR : J’ai capturé l’intégralité du flux réseau dans un fichier HAR. Il montre que la requête POST vers /session pour la connexion réussit. Le serveur répond immédiatement avec une redirection 302 Found, mais l’en-tête Location est systématiquement /. Cela prouve que Discourse abandonne intentionnellement la redirection SSO.
Journal Rails vide : J’ai ensuite suivi le fichier production.log à l’intérieur du conteneur lors d’une tentative de connexion. Absolument rien n’est écrit dans le journal pendant ce processus. Cela me dit que Discourse ne considère pas cela comme une erreur ; c’est une action délibérée et silencieuse.
Ma question : Étant donné que la connexion réussit, mais que la redirection est incorrecte et qu’il n’y a aucune erreur dans les journaux, quelle politique interne de Discourse, vérification préalable ou paramètre caché pourrait l’amener à ignorer le return_sso_url et à rediriger vers la page d’accueil à la place ? J’ai l’impression d’avoir épuisé tous les paramètres standards.
