Hello Discourse,
Sometimes people request that we change their SSO user name. With some services, it’s possible to change users’ external IDs so that they can continue using the same accounts on other sites. Would you be interested in adding this feature to the site, or should we devise an SQL query to change this in Discourse’s DB?
Thanks,
Andrew
Being able to change users’ email addresses too should help with collisions if an old account has an email address they would like to use on their new account. I know that this second request is more of an edge case, but it could be useful.
I have a clarification about this issue, and a question about a work around.
By changing a user’s SSO name, what I mean is that sometimes people want their user name to be changed in our upstream CAS SSO server. This is easy for us to do, and we are then able to change external IDs on services that are clients to that CAS server. That means that users can still log into their old accounts with their new user name. It would be great if admins could update users’ External IDs in Discourse. Without this feature, we generally can’t change the user names of active forum users.
As a workaround, is there a way to change ownership of all posts written by a user? I suspect that would not be ideal, because there is a lot of additional metadata that can’t be transferred, like statistics and badges.
Thanks! 
Can you use the sync_sso endpoint, essentially that allows you to push any payload you wish via the SSO chain?
is sync_sso part of the normal authentication procedure? If so, then I suspect that providing a SSO payload with the new name would simply create a new account with that External ID.
I grepped for sync_sso in the Discourse CAS SSO service source code and there were no matches. I looked through the Discourse repo, but I’m not sure how to use that function, which appear to be accessible via /users/sync_sso.
Thanks for your help.
Yes. That is a normal route for our official SSO system.
Everytime a user login happens the data from SSO syncs with Discourse. If you need the sync to happen outside logins, you can call sync_sso anytime you need.
A new name with the same external_id should update the name of the user with that external_id if sso overrides username is true.
The CAS SSO is an unofficial plugin, and we don’t have experience with it.
That makes sense. However the issue here isn’t updating the user name of someone who logs in with an External ID of ‘bob’, but allowing Bob to log into the same account with the a new External ID of ‘alice’. In order to do so, it looks like the External ID of Bob’s account needs to be changed from ‘bob’ to ‘alice’.
If sso_sync is the way to go, would I simply need to craft a JSON payload and pass it to that URL? I think that this use case is common enough that having a guide or some pointers would be super helpful. Maybe I just need to read up on how to create a custom SSO service? Thanks!
Why are you updating the external_id? The external_id is supposed to be a immutable identifier of the user in the auth source, like the ID column from the database or a long UUID, or anything stable.
From the documentation:
I’ve just encountered a situation where I think changing the external ID is legitimate. One of our users has moved from one school to another, and when they did this, they were assigned a new account – with a new UUID and email address. They’ve since started using this account to connect with other third-party applications.
They then realised that they could no longer access their account on our Discourse instance – they had a new user created.
At this point, I should have got in touch with the Discourse team to merge the accounts, but I thought I might be able to get away without doing so…
I updated their email address on the old account so that it matches their new email address – but they’re unable to log in because the external ID they’re using doesn’t match that account, and a new account can’t be created because the email address is in use. If I could simply edit their external ID, it would mean they could carry on quite happily.
I understand why there would be concerns around making a “merge user” function easily accessible from the admin interface; my feeling is that being able to edit the external ID for a user would likely mean that many merges aren’t necessary.
(As it stands, I’m seeing if I can change the UUID in our system for this user, but if they’ve used it to access other third-party systems, I’ll end up having to ask the Discourse team to help me out… 
)
You are correct!
From every point of view this is a different user, it just happens to be the same person operating the new account.
We’re happy to help you with this, just PM @team the details of which user needs their external ID wiped or usernames to merge.
Thanks @supermathie! I managed to sort this one by changing the UUID on our side (thankfully the user hadn’t yet made use of this UUID for other apps!), so all’s good for now. 