We’re using an in-house SSO provider which authenticates against LDAP. We’ve extended the core functionality so that, when the user authenticates, the provider retrieves a list of groups from Discourse and then populates the add_groups and remove_groups based on that list of groups combined with group membership in LDAP.
In order for that to work with multiple Discourse sites, the SSO provider needs to know the URL of the Discourse site that is requesting the authentication.
I did have this working by retrieving the HTTP_REFERER value but the referer field is no longer being populated for some reason. As a result, I’m now have to run two SSO providers running identical code.
I don’t think that Discourse provides the site URL when calling the SSO provider, and I can’t think of another way for the SSO provider to get the site URL if referer isn’t being populated.
Would it be possible to extend the Discourse SSO specification so that the site URL is provided to the SSO provider?
Surely the more logical extension would be to allow an exactly_these_groups parameter, so you don’t have to fiddle around with add_groups and remove_groups?
I’ve run into similar issues with WordPress multisite and SSO. This isn’t implemented in the WordPress plugin, but you could try adding a query parameter to the sso_url that you set on Discourse. It could be used to determine which forum the request has come from.
Yes, I did discover that in the research I did yesterday. We’re definitely sticking to HTTPS - HTTPS. I found a Mozilla blog article explaining why referer was a bad idea generally, which is partly what prompted me to ask for ideas about how to solve this without that dependency.
The problem is that there isn’t a 1:1 match between Discourse groups and LDAP groups in our infrastructure. We only have a few Discourse groups and I didn’t want to hard-code those into the SSO provider - I wanted the SSO code to query Discourse to get the group names, hence the need for the Discourse URL.