When a user is deactivated, his SSO data is not deleted

[dklimpel]

Description:

I cannot find a call to delete user's SSO mapping when user is deactivated.

synapse/synapse/handlers/deactivate_account.py

Line 54 in 4044442

async def deactivate_account(

IMO it should be deleted.
In addition there needs a background job to clear old SSO mappings for deactivated users.

[DMRobertson]

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?

[clokep]

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).

[dklimpel]

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.

[clokep]

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:

1. A user has an account with an SSO provider.
2. They use that SSO provider to log into Synapse (and implicitly create an account).
3. There account is deactivated.
4. They attempt to login via SSO and are told their account has been deactivated.

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.

[richvdh]

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?

[richvdh]

Related: note that Synapse's implementation of the C-S API includes undocumented support for the erase flag: matrix-org/matrix-spec#297.

[fdr]

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)