Delegating Authentication

SonarQube comes with an onboard user database, as well as the ability to delegate authentication via HTTP Headers, GitHub Authentication, GitLab Authentication, SAML, or LDAP. Each method offers user identity management, group synchronization/mapping, and authentication.

Group Mapping

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

• membership in synchronized groups will override any membership locally configured in SonarQube at each login
• membership in a group is synched only if a group with the same name exists in SonarQube
• 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

HTTP Header Authentication

You can delegate user authentication to third-party systems (proxies/servers) using HTTP Header Authentication.

When this feature is activated, SonarQube expects that the authentication is handled prior any query reaching the server. The tool that handles the authentication should:

• intercept calls to the SonarQube server
• take care of the authentication
• update the HTTP request header with the relevant SonarQube user information
• re-route the request to SonarQube with the appropriate header information

All the parameters required to activate and configure this feature are available in SonarQube server configuration file (in $SONARQUBE-HOME/conf/sonar.properties).

Using Http header authentication is an easy way integrate your SonarQube deployment with an in-house SSO implementation.

GitHub Authentication

You can delegate authentication to GitHub Enterprise and GitHub.com using a dedicated GitHub OAuth application. Alternately, if you're using the pull request decoration provided as part of Developer Edition and above you can harness the GitHub application needed for PR decoration to also provide authentication.

Dedicated GitHub OAuth application

1. You'll need to first create a GitHub OAuth application. Click here for general instructions:

   1. "Homepage URL" is the public URL to your SonarQube server, for example "Administration -> General -> Server base URL
   2. For GitHub Enterprise "Authorization callback URL" and for GitHub.com "User authorization callback URL" is /oauth2/callback, for example "https://sonarqube.mycompany.com/oauth2/callback"

2. In SonarQube, navigate to Administration > Configuration > General Settings > Security > GitHub:

   1. Set Enabled to true
   2. Set the Client ID to the value provided by the GitHub developer application
   3. Set the Client Secret to the value provided by the GitHub developer application

On the login form, the new "Log in with GitHub" button allows users to connect with their GitHub Enterprise accounts.

Re-use GitHub PR decoration application

1. In the GitHub app, in Permission & events > User permissions: Add Read-only access in Emails.
2. In SonarQube settings, update the Client ID and Client Secret and use values defined in the GitHub app.

If you previously used a dedicated GitHub OAuth application for authentication, it can be removed.

GitLab Authentication

You can delegate authentication to GitLab using a dedicated GitLab OAuth application.

Create a GitLab OAuth application from your GitLab account. Click here for general instructions.

1. In the Name text box, name your app SonarQube.
2. In the Redirect URI text box, enter your SonarQube URL with the path /oauth2/callback/gitlab. For example, https://sonarqube.mycompany.com/oauth2/callback/gitlab.
3. Under Scopes, select api if you plan to enable group synchronization. You can instead select read_user if you only plan to delegate authentication.

After saving your application, GitLab gives you your Application ID and Secret. Keep these at hand, open your SonarQube instance, and navigate to Administration > Configuration > General Settings > Security to finish setting up GitLab authentication:

1. Set Enabled to true.
2. Enter the Application ID provided by GitLab in the Application ID text box.
3. Enter the Secret provided by GitLab in the Secret text box.

On the login form, the new "Log in with GitLab" button allows users to connect with their GitLab accounts.

GitLab group synchronization

Setting Synchronize groups to true at Administration > Configuration > General Settings > Security associates GitLab groups with SonarQube groups of the same name (if they exist). GitLab users inherit membership to subgroups from parent groups so a user that is a member of a group will also be a member of the group's subgroups.

To synchronize a GitLab group or subgroup with a SonarQube group, name the SonarQube group with the full path of the of the GitLab group or subgroup URL. For example, say you have a GitLab group named "My Group" with a subgroup named "My Subgroup" and the subgroup URL is https://YourGitLabURL.com/my-group/my-subgroup. You would name your SonarQube group my-group/my-subgroup to synchronize it with your GitLab subgroup.

SAML Authentication

You can delegate authentication to a SAML 2.0 Identity Provider using SAML Authentication.

Limitations

• SAML requests are not signed. Client signature validation should be disabled in the Identity Provider.
• SAML encrypted responses are not supported. SAML encryption should be disabled in the Identity Provider.

Example: Using Keycloak as a SAML Identity Provider

The following example may be useful if you're using Keycloak as a SAML Identity Provider. If you're not using Keycloak, your settings are likely to be different.

LDAP Authentication

You can configure SonarQube authentication and authorization to an LDAP server (including LDAP Service of Active Directory) by configuring the correct values in $SONARQUBE-HOME/conf/sonar.properties.

The main features are:

• Password checking against the external authentication engine.
• Automatic synchronization of usernames and emails.
• Automatic synchronization of relationships between users and groups (authorization).
• Ability to authenticate against both the external and the internal authentication systems. There is an automatic fallback on SonarQube internal system if the LDAP server is down.
• During the first authentication trial, if the user's password is correct, the SonarQube database is automatically populated with the new user. Each time a user logs into SonarQube, the username, the email and the groups this user belongs to that are refreshed in the SonarQube database. You can choose to have group membership synchronized as well, but this is not the default.

	Apache DS	OpenLDAP	Open DS	Active Directory
Anonymous
Simple
LDAPS
DIGEST-MD5
CRAM-MD5
GSSAPI

= successfully tested

Setup

1. Configure LDAP by editing $SONARQUBE-HOME/conf/sonar.properties (see table below)

2. Restart the SonarQube server and check the log file for:

   INFO org.sonar.INFO Security realm: LDAP ...
   INFO o.s.p.l.LdapContextFactory Test LDAP connection: OK
   

3. Log into SonarQube
4. On logout users will be presented a login page (/sessions/login), where they can choose to login as technical user or a domain user by passing appropriate credentials

From SonarScanners, we recommend using local technical users for authentication against SonarQube Server.

General Configuration

User Mapping

Group Mapping Only groups (not roles) and static groups (not dynamic groups) are supported. Click here for more information.

For the delegation of authorization, groups must be first defined in SonarQube. Then, the following properties must be defined to allow SonarQube to automatically synchronize the relationships between users and groups.

Sample Configuration

# LDAP configuration
# General Configuration
sonar.security.realm=LDAP
ldap.url=ldap://myserver.mycompany.com
ldap.bindDn=my_bind_dn
ldap.bindPassword=my_bind_password
  
# User Configuration
ldap.user.baseDn=ou=Users,dc=mycompany,dc=com
ldap.user.request=(&(objectClass=inetOrgPerson)(uid={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
 
# Group Configuration
ldap.group.baseDn=ou=Groups,dc=sonarsource,dc=com
ldap.group.request=(&(objectClass=posixGroup)(memberUid={uid}))

Advanced LDAP Topics

Authentication Methods

• Anonymous - Used when only read-only access to non-protected entries and attributes is needed when binding to the LDAP server.
• Simple Simple authentication is not recommended for production deployments not using the ldaps secure protocol since it sends a cleartext password over the network.
• CRAM-MD5 - The Challenge-Response Authentication Method (CRAM) based on the HMAC-MD5 MAC algorithm (RFC 2195).
• DIGEST-MD5 - This is an improvement on the CRAM-MD5 authentication method (RFC 2831).
• GSSAPI - GSS-API is Generic Security Service API (RFC 2744). One of the most popular security services available for GSS-API is the Kerberos v5, used in Microsoft's Windows 2000 platform.

For a full discussion of LDAP authentication approaches, see RFC 2829 and RFC 2251.

Multiple Servers

To configure multiple servers:

# List the different servers
ldap.servers=server1,server2
  
# Configure server1
ldap.server1.url=ldap://server1:1389
ldap.server1.user.baseDn=dc=dept1,dc=com
...
 
# Configure server2
ldap.server2.url=ldap://server2:1389
ldap.server2.user.baseDn=dc=dept2,dc=com
...

Authentication will be tried on each server, in the order they are listed in the configurations, until one succeeds. User/Group mapping will be performed against the first server on which the user is found.

Note that all the LDAP servers must be available while (re)starting the SonarQube server.

Troubleshooting

• Detailed connection logs (and potential error codes received from LDAP server) are output to SonarQube's $SONARQUBEHOME/logs/web.log_, when logging is in DEBUG mode.

• Time out when running SonarQube analysis using LDAP Java parameters are documented here: http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/config.html. Such parameters can be set in sonar.web.javaAdditionalOpts in $SONARQUBE-HOME/conf/sonar.properties.