Is Discourse SSO the solution to all our login related problems?

Archives Community Ops/Discourse
#1

I think so.

https://meta.discourse.org/t/official-single-sign-on-for-discourse/13045

Discourse SSO (Single-Sign-On) allows us to do all authentication and sign-up off of the Discourse site. Now you may ask, why on Earth would we want to do this?

I see two main reasons: it allows us to reclaim the after_authenticate hook for mozillians.org related purposes and it gives us complete control over users’ usernames.

To expand on the first reason: the current method for pulling data from mozillians.org (which is being used here: http://csa-discourse.mofostaging.net/, code here: https://github.com/LeoMcA/discourse-persona-mozillians) works by querying the mozillians.org api after a user logs in, and then doing stuff (like assigning them to groups). The trouble is, if we want to add another authentication method (e.g. Yahoo login) there’s no way we can use the after_authenticate hook to query mozillians.org without either patching the Yahoo login code in Discourse every time we do a git clone/pull, or reimplementing the Yahoo login as a plugin.

Using SSO would mean I would, in this case, have to add code to allow Yahoo login to the SSO server, but this isn’t any more difficult than doing it in Discourse, and things are far less likely to break after upgrades (because, in theory, the SSO protocol should remain backwards-compatible).

The primary advantage I see for doing this is if (or when) we have separate Discourse instances for Mozilla communities. Suppose the Germany speaking community wanted their own separate Discourse instance. Using SSO would allow us to have one authoritative Discourse instance when it comes to usernames (which would probably be this one).

This would mean, for instance, if someone tried to sign up with @leo as their username on the German instance, they wouldn’t be allowed, and if somebody signed up on the German instance with a yet-unused username on the authoritative Discourse instance, their username would be reserved on it.

As for disadvantages, the only two I can see are that we have to build this (and I’ve already got a near-equivalent system working to what we have on this site already) and host it (but we’re not too shabby at that). There’s no problem of storing user data, most of what this SSO server will be doing (at least initially) is combining data from a number of apis, and then handing it off to Discourse.

There’s an Etherpad summarising most of this information (and a few development notes): https://communityit.etherpad.mozilla.org/discourse-sso

Thoughts?

2 Likes
SSO isn't the solution to all our login related problems
#2

So, the thing here is to build a SSO server, which will get users from mozillians and can be used in any Discourse instance, right?

What about users that don’t have/don’t want to have a mozillians account? I’m thinking about external people who wants to just discuss about a particular topic but don’t get involved more with Mozilla.

#3

It could be used with any Discourse instance we set up, and the idea is if a user hasn’t yet signed up, we get their nickname and real name from mozillians.org, but then allow them to modify it if they want (in the sign up process). So for users who haven’t yet got/don’t want a mozillians.org account, they’ll just be presented with a blank form to put whatever username and real name they want in.

#4

I’ve been working with @leo on this for a bit to see if it’s feasible to do this, and I think it would be beneficial. We still won’t have to worry about storing logins and we can have people sign up for an account once that works across many Discourse instances - Something that would be a blocker for having multiple community instances.

2 Likes
#5

For the record, at Mozilla Hispano we are migrating our old phpbb to a local Discourse instance in January, it would be awesome to be able to have this integration, but I don’t know if it would work with a instance with thousands of already existing users :wink:

#6

How does the user migration work? Are users required to sign up again? Or are all their details (including passwords?) migrated across?

I’m sure we’d be able to find some way to make it work, even retaining this Discourse instance as the authoritative one.

#7

All user data is migrated, except passwords since they use a different hash. Users have to reset their passwords or log in with their emails using persona.

#8

Okay, it would be perfectly doable to integrate the Mozilla Hispano Discourse instance - the only trouble would come when there’s a clash (if there’s a clash) between a user’s old username and a username on this Discourse instance, or if people have used the same nick but different emails on each instance.

With the first problem, it would seem a little unfair to prompt a user to change their username, but if we weren’t to the ‘authority’ of this Discourse instance would break down.

As for the second problem, we could allow users on this Discourse instance to ‘whitelist’ other email addresses, allowing them to be assumed to be belonging to the same person.

#9

Question. Is this SSO server blocking the API integration with mozillians?

#10

No, but it would allow us to do more with the mozillians.org API, more easily.

http://csa-discourse.mofostaging.net has https://github.com/LeoMcA/discourse-persona-mozillians running on it, which means that when you login, you’ll be placed in either a vouched or unvouched mozillians.org group (or no group at all, if that email isn’t on mozillians.org). I’ll be easy enough to add being placed in an nda group, once I’ve requested (and passed) a privacy review. Allowing arbitrary mozillians.org -> Discourse group mappings would be easier to do using the SSO solution.

There’s no reason we can’t throughly test the plugin on staging, then in the next Discourse upgrade deploy it on prod (@yousef?), all while working on the perfect SSO solution in the background. To the user, the plugin being used on stage is no different to the current Persona plugin (albeit a little bit slower, while it queries mozillians.org).

#11

Checking the code I have some questions:

  • Do we really need to hack the Persona plugin to add/remove people from groups on login?
  • Can we do the same post_authenticate things for all kind of logins?

A plugin just for the second thing would be easier to maintain I think.

#12

Sadly not, hence my SSO proposal. The only way to use the after_authenticate hook is if you’re implementing your own login provider, which is why I’ve built upon the Persona plugin.

#13

Once it’s been tested and the code has been reviewed by an experienced Ruby dev, yes.

#14

Do we have people identified for this task or do you need help?

#15

Would need help to find Ruby developer to look over the code and check there are no major errors.