Open dklimpel opened 2 years ago
I think deactivating a user clears their password---sounds reasonable that other login-related information is reset too.
Is this about removing redundant data, or is it possible to log in with the SSO mapping even if you've been deactivated?
I'm not sure I agree that this should be removed. If it was removed than the user would likely be able to login as a new user. By keeping the SSO mapping we ensure that the SSO identity is mapped to the same user (internally).
Isn't that data that has to be deleted according to the GDPR? If someone does not use SSO, only password, he has no chance to reactivate his user. If the SSO id is something like an mail address and the user deletes his mail address and someone new register this address, he can take owenership over the account from someone others. IMO Synapse respectively Matrix.org has no implementation/chance for reactivate the right user. After deactivation you have to be sure to identify the right user.
If the SSO id is something like an mail address and the user deletes his mail address and someone new register this address, he can take owenership over the account from someone others.
The SSO ID must be a unique, immutable identifier to be valid. Using something that the user can change is a configuration error (one which Synapse could not detect, it full depends on your setup).
Most SSO providers have some sort of incrementing ID or GUID you should use here.
IMO Synapse respectively Matrix.org has no implementation/chance for reactivate the right user. After deactivation you have to be sure to identify the right user.
I'm not sure I understand what you're saying here. I'm picturing the following:
Is this the same chain of events you're thinking of?
I suppose the reason for the deactivation is important here -- if the user is deactivated in order to ban them you would not want them to be able to log back in using the SSO identity; if the user is deactivated just to delete their account than creating another account in the future might make sense.
I suppose the reason for the deactivation is important here -- if the user is deactivated in order to ban them you would not want them to be able to log back in using the SSO identity; if the user is deactivated just to delete their account than creating another account in the future might make sense.
I think this is covered by the erase
flag in the deactivate request.. Typically this is set to true for GDPR-erasure requests, but left as false for abuse-based deactivations.
So, we could just remove the SSO mapping if erase == true
?
Related: note that Synapse's implementation of the C-S API includes undocumented support for the erase
flag: https://github.com/matrix-org/matrix-spec/issues/297.
Note that this issue relates to the extremely verbose gitter.im usernames for those of us who ever used gitter.im before it was all Matrix: I will have to live with being @fdr-5914ce52d73408ce4f5edf1a:gitter.im
for all-time, my eternal reward for having used gitter.im in the past. I can't opt to purge my account and log in again to obtain a sensible username (such as fdr, like on github)
I have the same issue - an old verbose username when I first connected GitHub to gitter years ago. Since I could not change my gitter username, I deactivated my gitter account in hopes I could rejoin again (with a more recent GitHub username), but am now unable to login to gitter via GitHub.
I also attempted deactivation to get rid of the junk in my username, but I also cannot log in or create a new account with GitHub, currently the only provider that directly uses the username. Is this eventually going to be possible?
Description:
I cannot find a call to delete user's SSO mapping when user is deactivated. https://github.com/matrix-org/synapse/blob/404444260a89f18265c34b75ba7f64ab09e3a39c/synapse/handlers/deactivate_account.py#L54
IMO it should be deleted. In addition there needs a background job to clear old SSO mappings for deactivated users.