Je cherche à mieux comprendre nos options pour un projet de restructuration sur lequel je travaille. J’ai parcouru les forums pour obtenir plus d’informations et, bien que j’aie trouvé une requête similaire, le scénario de l’OP est quelque peu différent du nôtre. Je crée donc ce nouveau sujet.
Nous avons actuellement un site WordPress à l’adresse domain.com configuré comme client SSO pour l’instance Discourse située à community.domain.com. Cependant, le site WP est en cours de réorganisation en un réseau multisite, par exemple sub1.newdomain.com, sub2.newdomain.com, etc., avec une instance Discourse séparée pour chaque site, par exemple forum.sub1.newdomain.com (ou idéalement sub1.newdomain.com/forum, si nous parvenons à régler la configuration en sous-dossier).
Nous souhaitons que nos utilisateurs aient une identité unique sur toutes les communautés, et nous savons comment synchroniser les utilisateurs s’inscrivant sur un sous-site WP à travers l’ensemble du réseau. Je comprends qu’une instance Discourse peut agir en tant que serveur SSO pour une autre, mais je n’ai pas pu trouver de confirmation sur la façon dont cela est configuré ou si cela fonctionne pour plusieurs clients Discourse.
Voici donc mes questions :
Dans le scénario décrit, est-il possible de configurer une instance Discourse, par exemple à auth.newdomain.com, pour agir à la fois comme serveur SSO pour le réseau WPMS et pour toutes les instances Discourse liées aux sous-sites ?
Si la réponse à la question précédente est oui, serait-il réalisable de configurer cette instance « serveur » pour ne fournir que des fonctionnalités liées à l’authentification ? Autrement dit, elle n’aurait d’autre fonction que d’être la « source de vérité » en matière d’authentification pour l’ensemble du réseau, quel que soit le site contre lequel un utilisateur souhaite s’authentifier. Ou serait-il plus approprié de recourir à une solution d’authentification externe à ce stade ?
Salut — cela est apparu pour moi puisque tu as fait un lien vers mon sujet original. Je vais laisser @simon donner son avis, mais une option qui peut ou non fonctionner pour toi (et qui serait beaucoup plus simple) consiste à configurer une seule instance Discourse et à utiliser des groupes pour séparer les forums. Tu peux envoyer les informations de groupe dans la charge utile SSO.
Cependant, avoir plusieurs forums avec un seul fournissant l’authentification unique devrait être assez simple (bien que je ne l’aie jamais essayé auparavant). Je pense que les étapes seraient les suivantes :
Ajouter le plugin WP Discourse et le configurer comme client SSO (dans les options du réseau)
Configurer le forum Discourse que tu souhaites utiliser comme fournisseur SSO (ajouter des clés secrètes à WP + Discourse, etc.)
À partir de là, lors de l’ajout de forums ultérieurs, ils seraient configurés comme clients SSO (et comme WP Discourse est configuré au niveau du réseau, tu n’aurais pas à modifier de configurations lors de l’ajout de nouveaux sites).
Merci beaucoup d’avoir partagé vos suggestions, @jakeols. Je sais que les groupes sont souvent suggérés comme alternative, mais ils ne conviennent pas à notre cas d’usage spécifique.
J’espère que @simon pourra nous éclairer sur ce qui est possible ou non dans ce contexte.
Vous pouvez utiliser Discourse comme fournisseur SSO sur un réseau multisite. Cette fonctionnalité n’est activée que si vous configurez un seul site Discourse comme fournisseur SSO pour tous les sites du réseau. La raison en est que, sur un réseau multisite, tous les utilisateurs sont stockés dans une seule table de base de données. Si plusieurs sites Discourse sont autorisés à fonctionner comme fournisseurs SSO pour plusieurs sites d’un réseau, il n’existe aucun moyen simple de garantir que les identifiants d’utilisateurs Discourse enregistrés dans WordPress soient uniques.
Lorsque le plugin WP Discourse est installé sur un réseau multisite, un onglet Discourse est ajouté au menu d’administration du réseau. Pour configurer Discourse comme fournisseur SSO pour tous les sites du réseau, accédez à la page d’administration du réseau et sélectionnez Discourse dans le menu. Cochez l’option « Activer la configuration multisite », puis remplissez les paramètres de connexion. Faites ensuite défiler la page jusqu’à la section Paramètres SSO. Cochez l’option « Activer le client SSO ». Entrez votre clé secrète SSO et enregistrez la page de paramètres.
Une chose à noter est que l’activation de la fonctionnalité du client SSO sur un réseau multisite peut potentiellement donner accès à n’importe quel utilisateur de votre forum Discourse à n’importe quel site de votre réseau.
En résumé, si vous essayez d’accomplir autre chose que cela en utilisant Discourse comme fournisseur SSO pour un réseau multisite WordPress, vous êtes livré à vous-même. Il serait techniquement possible de permettre à plusieurs sites Discourse de fonctionner comme fournisseurs SSO pour des sites individuels d’un réseau WordPress, mais la configuration requise serait excessivement complexe. Je ne pense pas que cela sera jamais ajouté au plugin WordPress.
Merci beaucoup pour votre réponse. Votre message cité correspondait à ce que j’avais mentionné dans mon message initial. Je n’ai pas vraiment de problèmes côté WordPress — nous savons comment nous connecter au niveau du réseau, puis synchroniser les utilisateurs sur tous les sous-sites. Ce que j’essaie surtout de comprendre, c’est comment configurer un Discourse pour qu’il serve de serveur SSO pour un autre. Je cherchais à clarifier s’il est possible de faire cela tout en ayant le Discourse « auth » qui sert également de serveur SSO pour WordPress en même temps.
Je n’ai pas réussi à trouver de documentation sur l’arrangement Discourse-Discourse. Si vous pouviez m’indiquer où trouver plus d’informations ou simplement décrire les étapes nécessaires, je vous en serais immensément reconnaissant.
Je comprends votre point de vue, mais Discourse n’est pas conçu pour être utilisé uniquement à des fins d’authentification. Je vous suggère de consacrer un peu de temps à l’étude d’un service d’authentification dédié que vous connecteriez à vos différentes instances Discourse et WordPress. Un petit investissement dans la recherche maintenant peut se révéler rentable plus tard.
Mon principal conseil à votre égard est que ce que vous proposez est complexe. Quelle que soit la voie choisie, vous devez mettre en place un environnement de staging qui reflète votre environnement de production prévu afin d’expérimenter différentes configurations avant le déploiement. Ce type de configuration peut être influencé par de nombreuses variables différentes, et il est difficile de donner des conseils à ce sujet de manière abstraite.
Je sais que l’idée de mettre en place un environnement de staging entièrement séparé pour un réseau interconnecté de serveurs peut sembler fastidieuse, mais le travail nécessaire à cela est bien moindre que celui requis pour résoudre des problèmes imprévus qui surviendraient une fois qu’un tel système aura été lancé.
Oui, je reconnais bien que Discourse n’est pas un service d’authentification pur. Nous envisageons trois options potentielles :
Utiliser Discourse comme fournisseur d’identité
Utiliser WordPress comme fournisseur d’identité
Utiliser un fournisseur d’identité externe (SaaS ou auto-hébergé)
Chacune de ces options présente des implications différentes en termes de coût, de complexité et d’expérience utilisateur que nous cherchons à évaluer, d’où mes questions ici.
Non, tu as tout à fait raison, c’est vraiment complexe et nous n’aurions jamais l’idée de déployer cela sans le tester d’abord sur un environnement de staging. Merci beaucoup pour les explications, très apprécié !
