About SSO and provisioning
This page provides an overview of the SSO authentication and provisioning solution in SonarQube Cloud.
This feature requires the SonarQube Cloud's Enterprise licence.
You can use the Single Sign-On (SSO) authentication mode in your enterprise with SAML or OIDC. With SSO you benefit from:
Increased security and a single source of truth for user authentication.
Automatic user and group provisioning through SCIM. If you don’t want to use SCIM, Just-in-Time (JIT) user provisioning is supported with the automatic group synchronization.
To set up SSO and provisioning in your enterprise, follow:
SSO authentication
You can use the SAML or the OIDC protocol.
Service Provider (SP) initiated SSO
SonarQube Cloud uses Service Provider (SP) initiated Single Sign-On (SSO). This process involves users attempting to log in to SonarQube Cloud, which then redirects them to your identity provider for authentication.
Identity Provider (IdP) initiated SSO is not supported (except through the Okta dashboard if you set up SSO with the Okta Express Configuration).
If you want to use a shortcut link to access the SSO login, use
https://sonarcloud.io/login/sso?enterprise_key=<enterprise_key>.
User login format
When creating a new user login, SonarQube Cloud systematically adds a random suffix to the login name to manage user misidentification risk.
When setting up API-based automations related to users, don’t use the login field to retrieve a user. Use the email field instead.
Domain verification
You can verify your company’s email domain through the SonarQube Cloud setup assistant. Once verified, the domain is associated with the SSO connection. This way, users logging in via SSO will not be prompted to enter a one-time password (OTP) to verify their email.
SAML SSO authentication flow
Users log directly into SonarQube Cloud with their SAML SSO credentials which are transmitted to an Auth0 server for authentication. Auth0 functions as the SAML service provider, bridging SonarQube Cloud and the identity provider.
The authentication flow is as follows:
The user enters their login for SAML SSO via SonarQube Cloud.
SonarQube Cloud redirects the authentication request to Auth0.
Auth0 forwards the SAML request to the SAML identity provider.
The SAML identity provider authenticates the user and generates a signed token containing the user’s information and privileges (SAML assertion). It sends the SAML assertion to Auth0. Optionally, the identity provider can encrypt this assertion with SonarQube Server’s certificate. Note that in that case, the SAML response, which contains the encrypted assertion, must be signed.
Auth0 sends the token to SonarQube Cloud.
SonarQube Cloud receives the token, verifies its signature and performs extra-authentication checks. If successful, the user is authenticated in SonarQube Cloud.
Auth0 may connect to the identity provider from one of the IP addresses listed here.
OIDC SSO authentication flow
The authentication flow is as follows:
The user tries to log in to SonarQube Cloud.
SonarQube Cloud redirects the user to the OIDC provider for authentication.
The user authenticates to the OIDC provider using their credentials.
The OIDC provider generates an ID token and sends it to SonarQube Cloud.
SonarQube Cloud verifies the ID token and grants the end user access.
Limitations
In an SSO-enabled enterprise:
SSO users cannot be added to organizations outside of their enterprise.
The GitHub member synchronization is disabled on any organization of the enterprise.
Currently, an SSO user cannot bind a SonarQube Cloud organization to its corresponding Bitbucket Cloud workspace. They must use their DevOps platform (DOP) account to perform the binding.
Both DevOps platform and SSO authentications are supported but only one SSO configuration can be managed.
If you transition from the DevOps Platform authentication service to SSO: When created in SonarQube Cloud, SSO accounts will have no history. That means that comments on issues, favorite projects, etc., will not be transferred from the corresponding DevOps Platform account’s history in SonarQube Cloud.
With SSO, groups are mandatory. Users have access to their SonarQube Cloud organization only if they are members of a group within this organization.
SCIM provisioning
You can use SCIM provisioning in SonarQube Cloud alongside Single Sign-On (SSO) to automate the user on- and off-boarding.
SCIM provisioning is supported with any identity provider.
To set up SCIM provisioning in your enterprise, see Set up SCIM.
Supported provisioning features
SCIM automates user and group provisioning and deprovisioning. This includes the synchronization of group memberships. These features are illustrated in the figure below and detailed in the following paragraphs.
An SSO user has access to an organization (and is a member of this organization) if they belong to a group within this organization.
User and group permissions are set in SonarQube Cloud.
User provisioning
When you create a user in your identity provider and add them to a group assigned to your SonarQube Cloud application, the user is automatically provisioned in SonarQube Cloud.
User deprovisioning
When you remove a user from your identity provider or you deactivate an account, a user deprovisioning is enforced in SonarQube Cloud as follows:
All the user’s active sessions are revoked.
The user’s SonarQube Cloud’s SSO account is deleted.
The user’s personal access tokens are revoked.
Group provisioning
When you assign a group to the SonarQube Cloud application in your identity provider, it is automatically provisioned in SonarQube Cloud, provided it's mapped to the relevant SonarQube Cloud organization(s).
If a group with the same name already exists in a SonarQube Cloud organization, the members specified in your identity provider will be added to the existing group and any existing SSO member will be overwritten by the new member list (see also About SSO and provisioning).
Group membership synchronization
When you add or remove a user to/from a group in your identity provider, the membership of the corresponding SCIM group in the relevant SonarQube Cloud organization(s) is updated.
Group deprovisioning
When you remove a group from your identity provider, the group is removed from all SonarQube Cloud’s organizations it was mapped to. When you unmap a group from an organization in SonarQube Cloud, the group is removed from that organization.
SCIM provisioning flow
The SCIM provisioning flow with SonarQube Cloud is as follows:
The admin performs a provisioning operation in their identity provider, e.g. the admin adds a user to a group assigned to the SonarQube Cloud application.
The identity provider sends a SCIM request to SonarQube Cloud.
SonarQube Cloud interprets the request, e.g. SonarQube Cloud provisions the user.
Limitations and special cases
This section lists the limitations and special cases related to SCIM provisioning.
Limitations on management
SCIM provisioning and deprovisioning operations are performed exclusively in your identity provider. It means that you cannot perform the following operations in SonarQube Cloud:
Create or remove an SSO user.
Add or remove an SSO user to/from an organization.
Add or remove an SSO user to/from a SCIM group.
Add SSO users to a non-SCIM group.
Regarding non-SSO users:
You cannot add non-SSO users to a SCIM group.
You can still create groups manually in SonarQube Cloud in case you need to manage non-SSO users.
Users have access to their organization only if they are members of a SCIM group within this organization.
The user permissions of SSO users are defined exclusively in SonarQube Cloud through the groups they belong to.
SCIM group limits and provisioning rate
Due to constraints from Auth0, SCIM provisioning in your identity provider is subject to the following group limitations:
The maximum number of groups is 10,000.
The maximum number of members in a single group is 200,000.
Nested groups are not supported.
In addition, the connection with your identity provider is limited to a maximum of 25 requests per second.
Special case of existing groups with non-SSO users
If a SCIM group contains non-SSO users (this may be the case if the group existed previously within the organization):
The only manual operation permitted on this group in SonarQube Cloud is the manual removal of non-SSO users.
If you remove this group in your IdP or unmap it from an organization, the SSO users will be removed from the group in SonarQube Cloud but the group itself and the non-SSO users will not be removed.
Just-in-Time provisioning
If you choose not to configure auto-provisioning as part of your SSO authentication setup, SonarQube Cloud uses Just-In-Time (JIT) provisioning. This means that a user's SSO account is automatically created in SonarQube Cloud upon their first login using SSO.
With JIT provisioning, automatic group synchronization is supported.
Automatic group synchronization
With the automatic group synchronization:
A user in SonarQube Cloud is automatically added to an organization’s group within the enterprise if the user is a member of a group with the same name in the IdP. (The check is case-sensitive and excludes the organization’s default Members group.)
The users added to a SonarQube Cloud group become members of the respective organization. This is the only way a JIT SSO user is added to an organization. Note that if a user cannot be added to any group in SonarQube Cloud, they will land on an empty organization page.
See User group concept for more information about user groups in SonarQube Cloud.
If a group with the same name is assigned to several organizations, the user account is added to all these groups and thus, is a member of all these organizations.
JIT SSO users' group memberships are reset to match those in your identity provider upon login. If you add a JIT SSO user to a SonarQube Cloud group that doesn't exist in the identity provider, the user will be removed from that group on their next login.
Related pages
Related online learning
Last updated
Was this helpful?