Overview

SonarQube comes with an onboard user database, as well as the ability to delegate authentication via HTTP headers, GitHub, GitLab, Bitbucket Cloud, SAML, or LDAP. Each method offers user identity management, group synchronization/mapping (group synchronization is not supported for Bitbucket), and authentication.

Supported authentication methods

You can use one of the following authentication methods to allow the same authentication between SonarQube and your authentication system:

• HTTP header
• LDAP
• SAML with:
  • Azure AD
  • Keycloak
  • Okta
• GitHub 
• Bitbucket Cloud 
• GitLab 

Group synchronization

When using group synchronization, the following details apply regardless of which delegated authentication method is used:

• Membership in synchronized groups will override any membership locally configured in SonarQube at each login. When enabling group synchronization in the UI, manually added group memberships get reset.
• Membership in a group is synced only if a group with the same name exists in SonarQube. Administrators must first create the groups in SonarQube; to do this, navigate to Administration > Security > Groups and select Create Group.
• Membership in the default group sonar-users remains (this is a built-in group) even if the group does not exist in the identity provider.

Please see each Provider's unique Authentication page as linked to above for specific details about group syncing with each service.

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.

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 web service /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.

This feature has the following limitations:

• Deleting the personal information of a user will change their 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.