Official Single-Sign-On for Discourse (sso)

sso

#252

I’m wondering how does the SSO code handle this case:

  1. User creates account on sso.example.tld
  2. User signs on to forum.example.tld
  3. User goes to profile on sso.example.tld and changes their email address
  4. User then goes to forum.example.tld

At step 4, will Discourse still be able to figure out that the User from sso.example.tld with a changed email address is the same user in Discourse’s User database that has the user’s old email address stored?
If it can’t and instead creates a new Discourse user for that person because of the changed email address then that would be confusing and problematic for the user and the admin.


(Becky Herndon) #253

I just went through this same research. After the account is created, every time User’s payload is sent to discourse this will happen.

The User is logged into the forum account associated with your external ID, and it will change the email address to User’s new address.


(Felix Freiberger) #254

Note that this only happens if sso overrides email is on – otherwise, the address submitted via SSO is only used for the first lookup or when the account is created.


(Jeremy) #260

Is there any way to automatically sign them in when they hit the discourse forums, if they are already logged into our system? If do they always have to hit “Login” on the discourse forum first?


(Felix Freiberger) #261

If your forum should only be available to SSO users, you can enable the require login site setting, and users will be logged in automatically. If not: I don’t think there is an easy way to do it.


(Dylan Damsma) #262

What I’ve done is sending users that are logged in on our platform to the link:
discuss.example.com/login

and those that are not logged in to:
discuss.example.com

Not sure if it’s the right method, but seems to work for us.


(Jesse Perry) #263

Is there a way to disable #3 in this list and make the login fail if the user doesn’t already exist (if external_id or matching email doesn’t match) on the Discourse?


(Ionut Georgian Ciobanu De Radu) #265

Two questions:

  1. Why is there a \n added to the end of the the base6d encoded string?
  2. Could you please provide a complete payload and signature example to send to Discourse?

1c884222282f3feacd76802a9dd94e8bc8deba5d619b292bed75d63eb3152c0b TODO update example - this is not correct signature


(Brett Wallace) #266

Quick question if anybody has a minute to answer.

If a user is inactivated on the site used for SSO, how does discourse know/handle it?


(Felix Freiberger) #267

It doesn’t – it’s the SSO site’s responsibility to handle this. It should prevent new sign-ins and possibly log the user out remotely via the API*.

*It would be awesome if Discourse had an API to log out users using their external_id


(Kane York) #268

Yeah, right now that takes two requests - first is /users/by_external and second is the log out.


(Guss Davey) #269

What if I want to do it a different way round. I want Discourse to register the user, but then I want to pull the data to my home site, for the additional non forum features I provide my customers?

OR authenticate my websites login again Discourse (being the end point)


(Daniel Lynch) #270

@Guss I think what you want is Using Discourse as a SSO provider


(Sam Saffron) #282

Note, I just added optional rich logging for SSO via:

This site setting verbose_sso_logging can help you debug your SSO provider, however, be careful it gets very loud… only enable while you are debugging issues with your provider.


(Blake Erickson) #372

I created a very simple but working example SSO Endpoint that anyone can use for testing or learning how SSO works:


Bratwurst: the wurst possible production SSO provider
(Karl Romanowski) #405

Bit of an odd case here, I want to use Discourse SSO but my site doesn’t collect emails. Is there a way to send the username and name to Discourse, but then have Discourse collect and validate the email? Otherwise I can just create a page that collects and validates emails before redirecting back to Discourse.


(Blake Erickson) #406

I’m pretty sure “email” is a required field, so you have to pass in a dummy email, and then you can set require_activation to “true”:

I’m not sure what happens at this point though. They might not be able to log in without a valid email first. But if they can login, they can then reset the dummy email to a valid email. But I’m not even sure if that is possible because I think we send an email confirmation to the old email before changing it, but that might be just for admins. Anways, you might just have to try it on a test setup and see what happens.


(Kane York) #407

Another option is to implement it as an oauth2 basic/custom provider instead; if it’s the only enabled login method you get a similar (but slightly different) experience.

(Your provided usernames & avatars will not be enforced, cannot use sync_sso, invites will be enabled…)


(Sam Saffron) #408

:warning: WARNING

If you want any help or support post a #dev:sso topic

This giant discussion is becoming both unwieldy and confusing.

Any posts made below :arrow_down_small: will be deleted.

Keeping this open just so people don’t find a “closed” discussion.


(Simon Cossar) #414

A post was merged into an existing topic: Sync SSO user data with the sync_sso route