Discourse SSO Requirements

While going through the development plan of Plato today, we defined a set of requirements that we need to resolve somehow. We’re hoping to find a solution that fits, but it’s possible that we have over-specified our way into a dead-end.

Very short brief

Plato is the umbrella term for a package of software to steward grassroots organized places and events. It’s a package that we will offer as a bundle that comes with a tried and tested methodology, but all the different components of Plato can also be run on their own. Some of the software of Plato is custom built from scratch while other parts are slightly modified or extended versions of available open-source software.

  • Plato Dreams helps an organization come up with, refine and prioritize between projects to work on and fund. It is similar to an internal Kickstarter, but where projects are tied to a collective fund that resources are distributed from by the org members. Dreams has a GraphQL API.

  • Plato Realities helps an organization keep track of who is responsible for what, what the dependencies between responsibilities are, and how these responsibilities are carried out. It has a GraphQL API.

  • Discourse is the preferred discussion platform for Plato. When Dreams is paired with Discourse, each Dream has a Discourse thread that serves the comment section to Dreams through the Discourse API. When not paired with Discourse, Dreams has its own native comment system. Discourse has a REST-API.

  • Edgeryders OpenEthnographer and Graphryder are used in Plato when paired with the Edgeryders flavor of Discourse, to enable ethnography of a community conversation.

  • Plato Discourse plugin is planned to allow a user to label a thread on Discourse as belonging to a specific Dream or Reality by selecting from a list of options relevant to the organizations and events the user has access to.

  • Pretix, an open-source ticket platform, can be paired with Dreams to issue tickets to community events. Having a ticket on Pretix to an event on Dreams allows a user to participate in project creation and participatory budgeting. Pretix can be extended with plugins. Pretix has a REST-API.

We are building Plato in 2020-2021 and testing it at Blivande and Frihamnstorget. We will run at least two festivals at Frihamnstorget using Plato during this time – one in the fall of 2020 if the situation allows for it, and one in the spring of 2021.

In 2021 we (SenseStack/Edgeryders) aim to sell Plato to clients who manage places, organize festivals, want to try participatory conferences, or need innovative ways for community engagement.

Requirements and preferences

  • We want Dreams, Realities, and Discourse to be separately deployable and still be useful

  • We want to enable a single sign-on to Dreams, Realities, and Discourse.

  • We want to control which organizations a user belongs to on Dreams and Realities from a single place.

  • We want to have access to the Edgeryders ethnography software on Discourse

  • We want the Blivande Edgeryders forum to host the first iteration of Plato for Blivande

  • We prefer the SSO integration to Dreams and Realities to be based on a protocol like OAuth2 that makes it likely to work with potential future client SSO requirements.

  • We want user bios, avatars, and contact details to be set in Discourse when Plato is deployed with Discourse, and that information could then be displayed on Dreams and Realities.

  • We want to give a user access rights to the right Dreams event automatically when a ticket is issued to that user through Pretix.

  • We want the Pretix ticket issuing flow to involve a step (through a Pretix plugin) where a user either logs in with their existing SSO account or signs up for an account through a single step.

  • We would like the confirmation e-mail for a new account registered through the Plato Pretix to be contextual, for example welcoming a user to the Festival community on the Blivande forum.

  • We want our chosen solutions to be scalable with Dreams, Realties, Discourse and Pretix deployed for production where new organizations can be added at a manageable cost.

Coming up with a solution

Alternative 1: Using Discourse as the SSO provider

Our first go-to solution was to use Discourse as the SSO provider and id-provider. This would look something like this:

Problem 1: Non-standard solution

To the best of my understanding, there is a recommended way for how to use Discourse as an SSO provider. However, it looks a bit hacky and very specific to Discourse. This is contrary to one of our preferences:

  • We prefer the SSO integration to Dreams and Realities to be based on a protocol like OAuth2 that makes it likely to work with potential future client SSO requirements.

Problem 2: Org membership

How would we define belonging to an organization on Edgeryders communities? When a user logs in with their SSO enabled account to Dreams and Realities, we need to be able to pass information from the SSO provider on which organizations the user is a member of. One way to do this could be through defining groups on Edgeryders Communities, but I don’t know if that would work as expected.

Problem 3: Confusing registration process

A user who just wants to participate in an event and buys a ticket to that event will get confused by getting a confirmation email from “Edgeryders Communities”. Seeing that I’m just getting people at Blivande used to Edgeryders, it’s a bit much to ask from someone at the community entry-level.

Would it be possible to somehow keep track of where a registration originated from and send a confirmation email accordingly? Would it also be possible to automate bringing the user to the right sub-forum without having them need to click the right icon?

What comes to mind is a Discourse plugin where any number of custom parameter strings are paired with confirmation email massages and target URLs to continue to after email verification. Perhaps there are other, better solutions.

Alternative 2: Logging in with a third-party SSO

Another alternative that might work would be to add a stand-alone id and SSO provider like Keycloak to the Plato stack. However, since we want to use the Edgeryders fora for Plato, we would need to allow for a third-party SSO provider to act as an OAuth2 provider for Edgeryders Communities.

This solves all problems above but introduces new problems.

That would look something like this:

Problem 1: No idea if viable for Edgeryders Communities

I have no idea if this would work or if it would cause all kinds of problems.

Problem 2: Introduces an extra piece of software with marginal benefits

Adding another identity provider does not seem as elegant. However, using a dedicated id-provider also gives us access to standard auth protocols and a more powerful way to handle user permissions in a central place.


We need some help making sense of our options, and would love to work with @matthias and @daniel on this. What are your thoughts, do you have any ideas?

Hmm… I found this discussion, which clarifies the differences between SSO and Oauth:

And there is an Oauth plugin for Discourse https://www.discourse.org/plugins/oauth.html as well as one for SAML authentication https://www.discourse.org/plugins/saml.html

But I actually know very little about all of these protocols - maybe @matthias is more knowledgeable…

Thanks @daniel! How about this part?

Is this something you think we could solve by building a plugin? It would be pretty useful for other Edgeryders applications too…

Makes a lot of sense to me and is (somehow) possible. A Discourse plugin would be best, but I guess there will need to be at least a few Discourse core modifications as well to get this to work.

The basic decision is actually quite simple in my mind. :slight_smile: You can get OAuth2 based authentication with Discourse as a SSO provider, except not at the same time as this:

The Edgeryders Communities installation uses the Discourse custom SSO provider mechanism (for good reason, as it supports syncing various parts of the user account information out of the box). So that is it’s architecture, and additions to this ecosystems would follow that architecture.

We do not want to switch all of Discourse to OAuth2, as that would for example break Owen’s now.edgeryders.eu site that relies on the Discourse SSO mechanism right now. And we’d also not want communities.edgeryders.eu offering two different protocols for SSO – that would be ugly (right?), and unnecessary complexity with more opportunities for breakdowns.

The clean solution, if you want both OAuth2 and the connection to the Blivande Edgeryders Communities site via Discourse SSO as explained above, would be to supply Plato with these two SSO client mechanisms. Plato is the client here, in technical terms, and the client accommodates. Only one SSO mechanisms would be active in each installation, so we avoid the mess, at the cost of developing two SSO client mechanisms for Plato.

Makes sense?