I’m trying to get a clearer understanding for our options with a restructuring project I’m working on. I’ve been searching the forums to get some more insight and while I found a similar query, the OP’s scenario is somewhat different to ours, so I’m creating this as a new topic.
We currently have a WordPress site at domain.com configured as an SSO client for the Discourse instance at community.domain.com, but the WP site is being reorganised as a multisite network, e.g. sub1.newdomain.com, sub2.newdomain.com, etc and a separate Discourse instance for each site, e.g. forum.sub1.newdomain.com (or ideally sub1.newdomain.com/forum, if we can get the subfolder config sorted).
We want our users to have a single identity across all communities and we know how to sync users registering at one WP subsite across the entire network. I understand that one Discourse instance can act as an SSO server for another, but haven’t been able to find confirmation of how this is configured or whether this works for multiple Discourse clients.
So, onto my questions:
In the scenario as described, is it possible to configure a Discourse instance at, say, auth.newdomain.com to act as both an SSO server for the WPMS network and all of the Discourse instances linked to the subsites?
If the answer to the previous question is yes, would it be feasible to configure that “server” instance to only provide authentication-related functionality? Meaning, it would serve no purpose other than to be the authentication “source of truth” for the entire network, regardless of which site a user wished to authenticate against. Or would it be more appropriate to rely on an external authentication solution at this point?
Hey – this popped up for me since you linked to my original topic. I’ll let @simon chime on with their thoughts, but one option that may or may not work for you (and would be much simpler) is to setup a single Discourse instance and use groups to separate out the forums.You can send group information in the SSO payload.
However, having multiple forums with a single one providing SSO should be pretty straightforward (although I haven’t tried it before). I believe the steps would be:
Add WP Discourse plugin, and configure it as an SSO client (in network options)
Set up the Discourse forum you would like to function as SSO provider (add secret keys to WP + Discourse, etc.)
From there, when adding subsequent forums they would be configured as an SSO client (and since WP Discourse is setup at the network level, you wouldn’t have to touch any configs when adding new sites).
Thanks so much for sharing your suggestions, @jakeols. I know groups are the commonly-suggested alternative, but they don’t fit for our particular use-case.
I’m hoping @simon can offer some insights as to what is/isn’t possible here.
you can use Discourse as the SSO provider on a multi-site network. It is only enabled if you setup a single Discourse site as the SSO provider for all sites on the network. The reason for this is that on a multisite network all users are stored in a single database table. If multiple Discourse sites are allowed to function as the SSO provider for multiple sites in a network, there is no straightforward way to guarantee that the Discourse user ids saved on WordPress are unique.
When the WP Discourse plugin is installed on a multisite network, a Discourse tab is added to the Network Admin menu. To configure Discourse as the SSO provider for all sites on the network, go to the Network Admin page and select Discourse from the menu. Select the ‘Enable Multisite Configuration’ option and then fill in the Connection Settings. Then scroll down the page to the SSO Settings section. Select the ‘Enable SSO Client’ option. Enter your SSO Secret Key and save the settings page.
One thing to be aware of is that enabling the SSO Client functionality on a multisite network will potentially give access to any user on your Discourse forum to any site on your network.
Essentially, if you are trying to accomplish something other than this with using Discourse as the SSO provider for a WordPress multisite network, you are on your own. It would be technically possible to allow multiple Discourse site’s to function as the SSO providers for individual sites on a WordPress network, but the required configuration for that would be overly complex. I don’t think it’s something that well ever get added to the WordPress plugin.
Thanks so much for your response. Your quoted post was what I had referred to in my original post. I don’t really have any issues on the WordPress side of things — we know how to connect at the network level and then sync the users across all subsites. What I’m more trying to understand is how we can configure one Discourse to serve as the SSO server for another? I was trying to clarify if it’s possible to do this while the “auth” Discourse is also the SSO server for WordPress at the same time.
I’ve not been able to find any documentation on the Discourse-Discourse arrangement, if you could point me to where I can find any more information or just outline the necessary steps, I’d be immensely grateful.
I understand where you’re coming from, but Discourse is not intended to be used purely for authentication purposes. I would suggest you spend some time considering a dedicated auth service which you connect to your various Discourse and Wordpress instances. A bit of investment in research now can pay off down the ine.
My primary piece of advice to you though is that what you’re proposing is complicated, and regardless of the path you choose you need to set up a staging environment that mirrors your intended production environment to experiment with different configurations before you roll it out. This kind of setup can be affected by a number of different variables and it’s hard to give advice about it in the abstract.
I know the thought of setting up an entirely seperate staging environment for an interconnected web of servers may seem laborious, but the labor involved in that is alot less than trying to work through unforseen issues that arise once you’ve launched something like this.
Yes, I do recognise Discourse isn’t a pure auth service. We’re considering three potential options:
Using Discourse as our identity provider
Using WordPress as our identity provider
Using an external (SaaS or self-hosted) identity provider
Each of these presents different implications for cost, complexity and UX that we’re seeking to evaluate, hence my questions here.
No, you’re 100% correct, it is complex and we wouldn’t dream of deploying this without testing on a staging environment first. Thanks so much for the explainer, much appreciated!
