[GDPR] As a Che user, I want to have a possibility to delete all the data related to my account

[ibuziuk]

Is your task related to a problem? Please describe.

As a Che user, I want to have the possibility to delete all the data related to my account. Currently, curl -X DELETE http(s)://{che-host}/api/user/{id}` API only deletes a user from the db, but not from keycloak.

Describe the solution you'd like

In order to be GDPR compliant https://www.eclipse.org/che/docs/che-7/removing-user-data/#gdpr

curl -X DELETE http(s)://{che-host}/api/user/{id}`` should not only delete user from db, but also delete it from the keycloak

Describe alternatives you've considered

N/A

Additional context

in the next iteration, we could also consider removal all the k8s namespaces associated with the user (not part of this task - initially clenup of db + keycloak is enough)

[vparfonov]

Technically solve this issue not hard we can call KeyClock REST API on BeforeUserRemovedEvent, but problem is Che-server doesn't have KeyClock Admin password. Maybe we can add it as secret @skabashnyuk?

[ibuziuk]

@vparfonov can't we simply retrieve the secret during the che server startup (for the internal keycloak I mean). Basically we need to retrieve the che-identity-secret:

[skabashnyuk]

Can we cover this task as documentation? Explaining for admin what to do. I think Che server should not be responsible for deleting users from keycloak. They are already too much coupled. CC @l0rd

[ibuziuk]

@skabashnyuk we can document it, but we do need to automate this process - single API call removes all the user-related data

[vparfonov]

@l0rd What do you think? Looks like we need your point of view here.

[ibuziuk]

@vparfonov I believe Mario already provided his POV in the doc related issue - #17500 (comment)

[metlos]

Are we really sure we want to complicate Che with something that is IMHO a disputable solution? IMHO the IDM server is in the large percentage of cases used by more than just Che, in which case this functionality makes no sense.

Wouldn't it be easier to have a separate script/microservice dedicated to this rather than complicate Che server with something that only a (IMHO) small minority of users will appreciate?

[l0rd]

If the Che server creates a new user in Keycloak the Che server API should provide an option to delete every bit related to that user from Keycloak.

[alexeykazakov]

I also would like to notice that using DELETE http(s)://{che-host}/api/user/{id} programmaticaly is complicated because of AuthN.
If I'm not mistaken this API requires a user token. In case of Che/CRW operator and built-in Keycloak which is installed by the operator it's supposed to be an access token from that Keycloak. This is something only the user itself can get after logging into the Keycloak.
It's a problem in Dev Sandbox (aka Hosted Toolchain). In our setup it's a CRW operator with built-in Keycloak. Configured to use OpenShift OAuth. We can't programmaticaly generate a Che Keycloak user token to use DELETE http(s)://{che-host}/api/user/{id} endpoint.
There should be an option to use some Service Account or Che admin credentials or something like this to use that API.

[vparfonov]

This issue about removing user data As a Che user

[alexeykazakov]

#17541 (comment)

@l0rd pointed me to this issue as the upstream issue for deleting users on behalf of the user. @l0rd, @ibuziuk it seems that it's actually a different issue then? Do you have any issue for the Toolchain case or we need to create a new one?

[vparfonov]

Probably for Toolchain will be enough just disable user in Keycloak, in this case user can't login anymore and don't need to remove any data. WDYT @alexeykazakov ?

[alexeykazakov]

Unfortunately it won't be enough.

1. User deactivation usecase. The flow is the following:

• CRW in Dev Sandbox (aka Hosted Toolchain) configured to use OpenShift OAuth and use the existing {username}-code namespace for workspaces. User does not have permissions to create new namespaces.
• When user is deactivated he/she is basically removed from OpenShift. OpenShift user/identity/namespaces are deleted.
• If I just delete the user from the Che Keycloak without deleting the user from the Che DB too then when the user is re-activated (openshift user/identity/namespaces are re-created) then it's impossible to run/create a workspace anymore. Che tries to create a new namespace instead of using the existing {username}-code one for some reason. Maybe it's not using the correct OpenShift token in this case. I don't know.
• If user is also deleted from Che itself (not only from KC) then everything works.

2. GDPR. For GDPR requests we need to be able to fully delete the user from Che.

[skabashnyuk]

I just delete the user from the Che Keycloak without deleting the user from the Che DB too then when the user is re-activated (openshift user/identity/namespaces are re-created) then it's impossible to run/create a workspace anymore.

@alexeykazakov can you disable user instead of removing it from keycaloak?

[alexeykazakov]

If I don't delete the user from KC then I can't even login to Che after re-creating the OpenShift user.
Just for the clarification. During deactivation the OpenShift user and identity is deleted. Then the user can re-signup and the OpenShift user/identity are recreated.

[gazarenkov]

It seems we have more data associated with user which have to be deleted as well.
@skabashnyuk could you please help to identify those entities?

[skabashnyuk]

@gazarenkov you don't need to worry about that. All associated with user entities would be automatically removed during user removal.

[gazarenkov]

thanks, I probably misunderstand of what we previously discussed (specifically related to workspaces). Good to know!