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?
@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.
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.
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 (discourse.example.com and support.example.com), 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?
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.
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.