Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

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

Open
dklimpel opened this issue Oct 13, 2021 · 9 comments
Open

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

dklimpel opened this issue Oct 13, 2021 · 9 comments
Labels
A-Account-Deactivation "Deleting"/"Removing" a user, GDPR erasure (erased) A-SSO Single Sign-On (maybe OIDC) P3 (OBSOLETE: use S- labels.) Approved backlog: not yet scheduled, will accept patches T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.

Comments

@dklimpel
Copy link
Contributor

Description:

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

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
Copy link
Contributor

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
Copy link
Member

clokep commented Oct 13, 2021

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
Copy link
Contributor Author

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
Copy link
Member

clokep commented Oct 13, 2021

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.

@callahad callahad added P3 (OBSOLETE: use S- labels.) Approved backlog: not yet scheduled, will accept patches T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. and removed X-Needs-Discussion labels Oct 21, 2021
@richvdh
Copy link
Member

richvdh commented Oct 21, 2021

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
Copy link
Member

richvdh commented Nov 1, 2022

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

@MadLittleMods MadLittleMods added the A-SSO Single Sign-On (maybe OIDC) label Mar 14, 2023
@fdr
Copy link

fdr commented Mar 21, 2023

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)

@MadLittleMods MadLittleMods added the A-Account-Deactivation "Deleting"/"Removing" a user, GDPR erasure (erased) label Apr 3, 2023
@evie-lau
Copy link

evie-lau commented Apr 28, 2023

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.

@Lucent
Copy link

Lucent commented Aug 13, 2023

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Account-Deactivation "Deleting"/"Removing" a user, GDPR erasure (erased) A-SSO Single Sign-On (maybe OIDC) P3 (OBSOLETE: use S- labels.) Approved backlog: not yet scheduled, will accept patches T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.
Projects
None yet
Development

No branches or pull requests

9 participants