Is there any way to work around issues caused by letting users change their email addresses on an SSO authentication server?
Users of Discourse and SSO apparently must be configured to not allow users to change their email address. This probably also means that if a user or admin changes their email address on an authentication server, they will get a new account the next time they log in.
If we let people change their email addresses on Discourse, then they will have to change that one before they change their email address on the authentication server. If they do it the other way around, users will be confused by logging into Discourse and suddenly having a new account. Not everyone will ask us for help if this happens. If they do it in the right order, they still may have issues if they are not able to set an email address used by one of their other accounts on the authentication server. In addition, if someone mistypes their new email address in Discourse, they may not be able to log into the site. I suspect that Discourse doesn’t keep a log of old email addresses, so we may have no obvious way to know whether an email revert request is valid.
How can organizations that allow people to change their email addresses on their authentication server cope with this issue?
Users can change their email address on the authentication server and log into their existing Discourse account. When a user first logs in with SSO, a SingleSignOnRecord is created that associates the user’s Discourse ID with the external_id that you supply in the SSO payload. For users who have a SingleSignOnRecord, the external_id is used for authentication.
If you would like email addresses on Discourse to be synced with email addresses from your authentication site, you should enable the sso overrides email Site Setting. When this setting is enabled, the Discourse user’s email address will be updated on each login based on the email address supplied in the SSO payload.
@simon Thank you so much for clarifying my confusion! Thankfully, it sounds like that would work with our setup.
Is it dangerous to enable email address overrides if the email addresses are not validated by our authentication server? Would that incur the issue mentioned here:
I don’t know much about how the Discourse SSO integration works, but I wonder whether if there are problems beyond password reset issues if someone supplies an invalid email address to the site, either when first creating an account via SSO or later on.
Either way, it seems like validating email addresses upon first login and not overriding email addresses from the SSO server would be a safe way to go.
If you send the parameter 'require_activation' => 'true' in the SSO payload after a user changed their email address, Discourse will send the New User activation email to the user. They will need to visit the link in the email before they can log back into their account. The UI for this is a little confusing - it makes it seem that Discourse is creating a new account for the user. Your best approach is to ensure that emails are validated on your authentication server.
The big issue is for new users. Supplying an invalid email could cause them to be logged into an existing account. It’s really important to be validating emails on the authenticating site.
Thankfully, it sounds like that would work with our setup.