# Overview

SonarQube Server comes with its own user database, as well as the ability to delegate authentication via protocols and providers. Each method offers:

* user identity management
* authentication
* user and group provisioning
* group synchronization (optional for JIT provisioning)

{% hint style="warning" %}
For security reasons, it is highly recommended that the default built-in administrator group’s name ([user-groups](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/user-management/user-groups "mention")) be changed. If group synchronization is used, this group may be used to gain unauthorized access.
{% endhint %}

## Supported authentication methods <a href="#supported-authentication-methods" id="supported-authentication-methods"></a>

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:
  * Microsoft Entra ID
  * Keycloak
  * Okta
* GitHub
* Bitbucket Cloud
* GitLab

{% hint style="warning" %}
Using an authentication method that is not supported by SonarQube can lead to a security breach. Sonar declines any responsibility in this regard.
{% endhint %}

## User, group and permissions provisioning <a href="#user-and-group-provisioning" id="user-and-group-provisioning"></a>

There are two ways of provisioning users and groups in SonarQube Server: Just-in-Time (JIT) and automatic provisioning.

In both cases, permissions themselves are still managed in SonarQube Server. The most effective way to handle permissions is to give permissions to groups (vs. individual users) directly and/or use [user-permissions](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/user-management/user-permissions "mention"), then manage group membership using one of the provisioning methods.

### Just-in-Time provisioning <a href="#justintime-provisioning" id="justintime-provisioning"></a>

This is the default provisioning method. User accounts are created in SonarQube Server when users log in for the first time. Groups must be manually created by administrators. However, memberships are automatically updated at each user login.

**Group synchronization**

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

* Memberships in a group are synchronized only if a group with the same name exists in SonarQube Server. Administrators must first [user-groups](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/user-management/user-groups "mention").
* Memberships in synchronized groups override any membership configured locally in SonarQube Server. When enabling group synchronization, *manually added* group memberships get reset.
* Memberships in the default built-in *sonar-users* group remain even if the group does not exist in the identity provider.

For specific details about group synchronization, refer to each provider’s group synchronization section.

{% hint style="info" %}
When group synchronization is configured, group memberships can only be managed from the delegated authentication source, and the user’s groups are re-fetched with each login. It is not possible to use both manual group memberships and group synchronization (via your ALM integration) for the same user.
{% endhint %}

### Automatic provisioning <a href="#automatic-provisioning" id="automatic-provisioning"></a>

Users and groups are automatically synchronized using the identity provider as the source of truth.

The main benefit compared to Just-in-Time provisioning is that user and group deprovisioning also happens automatically and does not require administrator intervention.

SonarQube Server enables automatic provisioning for the following providers:

* Starting in [Enterprise Edition](https://www.sonarsource.com/plans-and-pricing/enterprise/):
  * [introduction](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/authentication/saml/ms-entra-id/introduction "mention") and [scim-provisioning-with-okta](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/authentication/saml/scim/scim-provisioning-with-okta "mention") (through the [overview](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/authentication/saml/scim/overview "mention")): Group and user synchronization.
* Starting in [Developer Edition](https://www.sonarsource.com/plans-and-pricing/developer/):
  * [github](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/authentication/github "mention"): Group and user synchronization. Project permissions are also synchronized and deprovisioned automatically.
  * [automatic](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/authentication/gitlab/provisioning-modes/automatic "mention"): Group, user, and project permission synchronization.

{% hint style="info" %}
You can enable automatic provisioning only with one identity provider. It means that you can only use Just-in-Time provisioning with other providers.
{% endhint %}

## User login format <a href="#user-login-format" id="user-login-format"></a>

When creating a new user login, SonarQube Server systematically adds a random suffix to the login name to manage user misidentification risk. See also **About user and identity provider IDs** in [ldap](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/authentication/ldap "mention") for more information.

{% hint style="warning" %}
If email addresses are used as login names in your SonarQube Server, make sure the Identity Provider doesn’t use the same email address with different letter cases, for example, `my.user@myorg.com` and `My.User@myorg.com`. Indeed, SonarQube Server performs a case-sensitive login name check but a case-insensitive email address check. The email address check’s purpose is to verify that the same SCM account is not associated with several SonarQube Server accounts (The [updating-scm-details](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/user-management/updating-scm-details "mention") should be unique.). If it’s not the case, SonarQube Server may reject a login attempt.
{% endhint %}

## Local user concept <a href="#local-user-concept" id="local-user-concept"></a>

If the automatic provisioning mode is enabled with a third-party identity provider (e.g. GitHub or GitLab), all users that are not auto-provisioned (i.e., manually created users, or through another identity provider Just-in-Time-provisioned users), are called *Local users*.

The actions you can perform on local users are restricted as follows:

* You cannot change user passwords.
* You can remove but not add a project’s permissions to local users. However, you can still define default project permissions with the [user-permissions](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/user-management/user-permissions "mention").
* You can remove but not add local users to a local group.
* You can still deactivate local users and remove local groups.

In addition, you cannot manually create users.

## Revoking tokens for deactivated users <a href="#revoking-tokens-for-deactivated-users" id="revoking-tokens-for-deactivated-users"></a>

When SonarQube Server 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 Server side. We recommend deactivating the user in SonarQube Server to ensure tokens associated with that user can no longer be used. See [deactivating-users](https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/user-management/deactivating-users "mention").