Accessing one discourse via two different SSO backends

My organization has been slowly rolling out discourse for a range of communication purposes, and everybody absolutely loves it. I’ve seen few projects anywhere that manage to combine big picture thinking and attention to detail so well. Thank you, to everyone who has built this wonderful thing.

A practical question: our discourse community is composed from two distinct groups, one of which is based in our Moodle learning management system and the other of which is based in our internal admin system. We’d like to implement single sign on functionality for both groups, but we’re unsure about the best way to proceed.

If we pointed two different subdomains at the same discourse, would it be possible to write a plugin that would route logins to one or the other SSO link based on the subdomain being accessed? Or, is there another, better way we should be thinking about this?


I’d recommend adding your admins to Moodle, but that’s just because I’m lazy.

Pretty much anything is possible with a plugin. Pointing multiple domains to discourse is probably not a solution.

The other solution would be to use oauth rather than sso, so then a user could choose which authentication service they want.


What’s the other system you’re using internally?

1 Like

@pfaffman - I appreciate your sharing your experiences. In the medium term, our goal is to integrate discourse with moodle as seamlessly as possible, so oauth selection isn’t desirable.

At the moment, we’re doing exactly as you say to add the admin team to moodle, but it’s getting a bit cumbersome as we roll out more complex group assertions in our SSO responses. It’s not that there’s a massive amount of work involved in adding people to both systems manually, but the extra step opens the door to human mistakes.

What challenges would you anticipate in using two different subdomains (e.g. and and routing the SSO this way?

ERPNext, which we use for our accounting, HR, project management, and related work.

1 Like

Would they be separate discourse instances? There’s no support for additional domains that I’m aware of, the domain is specified as the application is built, and only one SSO destination can be defined.

No, if they were it’d be easy. Our goal is to have our single discourse instance acessible via sso to our two distinct user groups.

Then you need to implement some form of identity management and make one of those two sources authoritative for SSO.

1 Like

I definitely understand that this is how it works now, but my question here is whether it’s possible (and sensible) to alter that behavior with a custom plugin.

You seem to suggest that the discourse instance can’t live at two different subdomains, for example, and that would definitely nix this whole thing from the gate. Just by editing our nginx config file, I’m able to access our single instance right now at two different subdomains ( and, but I haven’t done any real testing to know if this causes any underlying problems (with attachment references perhaps?). Are you suggesting that there are known issues with running a single instance with two different subdomains?

NOTE: I’m no wizard. I could be all wrong.

You might be able to use oauth and hide the other option. There could be some way to have the Moodle oauth an default so that regular users don’t know about it and you’d have a secret URL that redirected to your other oauth system.

The “S” in SSO is single.

Then I’d try using the Moodle API to add your admin staff to Moodle when something changes on that system.

I am not a talented plugin developer, but I can’t think of anything that wouldn’t be a challenge in this approach.

1 Like

SSO disables all local user login on the assumption that Discourse will receive a ‘single version of the truth’. All other sign-on methods are disabled, aside from the backdoor used for admins in emergency situations. Your users, their group memberships and other attributes can only originate from one place.

A second domain doesn’t work, no. Review the documentation on the steps required just to move your discourse to a new domain, it gives you a fair idea of why Discourse can’t be presented under two FQDNs.

Discourse isn’t going to be the only case where you see this either - you’re going to need to come up with an approach to IdM for future service integration, better to do it now before you’ve incurred even more technical debt.


In our case, the goal is to keep identity management very separate everywhere except discourse.

Our two user groups are just very different. The first group, identified authoritatively in our admin system, comprises employees and in-person students. This group will always be relatively small (hundreds), and all of the other service integrations we offer are available only to them. The second group lives entirely in Moodle. They’re relatively anonymous (enrolled in our open online courses), and they number in the tens of thousands. We’ve talked about implementing a unified LDAP or something similar, but keeping the mass of semi-anonymous accounts sequestered in Moodle actually works out pretty nicely for all other purposes.

Hearing both of you, I understand that the correct answer here is to just route everything through Moodle. From a user perspective, that’s not ideal, since it makes SSO require a second sign-in for some. But, especially if discourse can’t present under two distinct subdomains, I see why that’s the necessary approach.

In any case, thanks to both of you for the assistance! I’ll report back with whatever I figure out.