diff options
| author | cynthiabethea <108268296+cynthiabethea@users.noreply.github.com> | 2022-10-12 14:39:13 +0100 |
|---|---|---|
| committer | sonartech <sonartech@sonarsource.com> | 2022-10-12 20:03:43 +0000 |
| commit | 3810d7b2651827bca469c291340b8fb89fe61f3b (patch) | |
| tree | f9e38c64215acfec01d8f2bf7a491dd999d5506b | |
| parent | 3399bd00eb9d03efbb5608acd628176908fd4e3e (diff) | |
| download | sonarqube-3810d7b2651827bca469c291340b8fb89fe61f3b.tar.gz sonarqube-3810d7b2651827bca469c291340b8fb89fe61f3b.zip | |
DOC-189 Updates based on MMF validation comments (#6832)
| -rw-r--r-- | server/sonar-docs/src/pages/instance-administration/authentication/overview.md | 13 | ||||
| -rw-r--r-- | server/sonar-docs/src/pages/instance-administration/security.md | 5 |
2 files changed, 13 insertions, 5 deletions
diff --git a/server/sonar-docs/src/pages/instance-administration/authentication/overview.md b/server/sonar-docs/src/pages/instance-administration/authentication/overview.md index 892671ab71d..9efd51c462d 100644 --- a/server/sonar-docs/src/pages/instance-administration/authentication/overview.md +++ b/server/sonar-docs/src/pages/instance-administration/authentication/overview.md @@ -17,13 +17,16 @@ When using group mapping, the following caveats apply regardless of which delega ## Revoking tokens for deactivated users When SonarQube authentication is delegated to an external identity provider, deactivating a user on the identity provider side does not remove any tokens associated with the user on the SonarQube side. We recommend deactivating the user in SonarQube at **Administration > Security > Users** by selecting **Deactivate** from the  drop-down menu to ensure tokens associated with that user can no longer be used. -## Anonymizing users' personal data -SonarQube offers the possibility to anonymize the data of deactivated users. This comes in handy when you want to ensure that the personal data of past users is not retained, for example, for legal compliance. +## Delete users' personal information +SonarQube offers the possibility to anonymize the data of deactivated users. This comes in handy when you want to ensure that the personal data of deactivated users is not retained, for example, for legal compliance. + +You can delete a user's personal information by following the steps listed above to revoke tokens for any deactivated users and select the checkbox titled **Delete user’s personal information**. + +You can also delete personal information using the API. First, the user needs to be deactivated, then an admin can use the webservice `/api/users/anonymize` and pass to it the login of a deactivated user to replace all personal data of the user with anonymized data. Note that the admin is able to retrieve the logins of deactivated users by using `/api/users/search` endpoint with the appropriate parameter. -In order to anonymize data, the user first needs to be deactivated. Only then can an admin use the webservice `/api/users/anonymize` and pass to it the login of a deactivated user to replace all personal data of the user with anonymized data. Note that the admin is able to retrieve the (now anonymized) logins of deactivated users by using `/api/users/search` endpoint with the appropriate parameter. -Deleting user's personal information can also be achieved through UI, by following the steps mentioned in the paragraph above and checking the checkbox titled 'Delete user’s personal information'. This feature has the following limitations: -- Anonymizing a user will change its login, making it impossible to reactivate the user by recreating a user with the old login. +- Deleting the personal information of a user will change its login, making it impossible to reactivate the user by recreating a user with the old login. - The user’s login may still be stored in issue changelogs and the user’s login, name and email address may still be stored in audit entries. Audit entries are purged by default after 30 days. +- Deleted users may still appear in the list of authors and other locations due to SCM data. - Some columns in the database may contain parts of the user's login if the user was created before the instance was upgraded to SonarQube 8.3.
\ No newline at end of file diff --git a/server/sonar-docs/src/pages/instance-administration/security.md b/server/sonar-docs/src/pages/instance-administration/security.md index ad400c11226..ea193c43e30 100644 --- a/server/sonar-docs/src/pages/instance-administration/security.md +++ b/server/sonar-docs/src/pages/instance-administration/security.md @@ -86,6 +86,11 @@ An Administrator can manage tokens on a user's behalf via **[Administration > Se An Administrator can only create [user tokens](/user-guide/user-token/) on behalf of another user. Once established, a token is the only credential needed to run an analysis. Tokens should be passed as the value of the `sonar.login` property. +See the [Authentication overview](/instance-administration/authentication/overview/) for details on + + * revoking tokens for deactivated users. + * deleting personal user information. + ### Token Maximum Lifetime *The ability to configure a maximum lifetime for tokens is available starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html).* |