Crowd Plugin

Description / Features

This plugin allows the delegation of SonarQube authentication and author=
ization to Atlassian Crowd.

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 (au=
thorization).

Ability to authenticate against both the external and the internal auth=
entication systems (for instance, technical SonarQube user accounts do not =
need to be defined in Crowd as there is an automatic fallback on SonarQube =
engine if the user is not defined in Crowd or if the Crowd server is down).=

During the first authentication trial, if the password is correct, the S=
onarQube 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.

Requirements

Plugin

0.1

0.2

1.0

2.0

Crowd

2.0.2

2.0.2

2.0.2 - 2.2.x

2.1.0 - 2.8.x

Installation

Install the plugin through the Upd=
ate Center or download it into the SONARQUBE_HOME/extensi=
ons/plugins directory

General Configuration

Property

Description

Default value

Mandatory

Example

sonar.security.realm

To first try to authenticate ag=
ainst the external sytem. If the external system is not reachable or if the=
user is not defined in the external system, the authentication will be per=
formed through the SonarQube internal system.

Available since=
SonarQube 3.6. It replaces the property=
sonar.authenticator.class usage.=

None

Yes

Crowd (only possible value)

sonar.security.savePassword=
pre>

To save the user password in the S=
onarQube database. Then, users will be able to log into SonarQube even when=
the Crowd server is not reachable.

false

No

sonar.authenticator.createUse=
rs

By default, the SonarQube datab=
ase is automatically populated when a new user logs into SonarQube. Setting=
this value to false, makes it mandatory for a System adm=
inistrator to first declare a user through the SonarQube web interface befo=
re allowing this user to log into SonarQube.

true

No

sonar.security.updateUserAttr=
ibutes

If set to true, at each login, user's attributes (name and email) are re-synchronized. I=
f set to false, user's attributes are not re-synchronized=
.

Note that if set to false, user's attributes are =
synchronized just once, at the very first login.

Available since Sona=
rQube 3.6.

true

No

sonar.authenticator.downcase=

Set to true&nbsp=
;when connecting to a Crowd serv=
er using a case-insensitive setup.

false

No

crowd.url

URL of the Crowd server. Note that=
if you are using https with a self certified certificate, then you should =
install the server certificate into the Java truststore. Since vers=
ion 2.0 of the plugin the url must be the root URL of your crowd instance a=
nd not the /services/ endpoint like for previous versions of the plugin.

Example of LDAP Configura=
tion

SONARQUBE/_HOME/conf/sonar.properties

=20

#-------------------
# Sonar Crowd Plugin
#-------------------
# To first try to authenticate against the external sytem.
# If the external system is not reachable or if the user is not defined in =
the external system, the authentication will be performed through the Sonar=
Qube internal system.
sonar.security.realm=3DCrowd
# URL of the Crowd server.
crowd.url=3Dhttps://my.company.com/crowd/
# Crowd application name.
# Default is 'sonar'.
crowd.application=3Dsonar-prod
# Crowd application password.
crowd.password=3Dbar
# Don't use crowd for sonar account
sonar.security.localUsers=3Dadmin,sonar

=20

Advanced Configuration

Technical Users

Since SonarQube 4.2, technical users can be set. Technical users are aut=
henticated against SonarQube's own database of users, rather than against a=
ny external tool (LDAP, Active Directory, Crowd, etc.).

Similarly, all accounts not flagged as local will be authenticated only =
against the external tool. By default admin is a tec=
hnical account. Technical accounts are configured in SONARQUB=
E_HOME/conf/sonar.properties in the sonar.securit=
y.localUsers (default value =3D admin) property as a comma=
-separated list.

to SonarQube 5.0

from Crowd plugin 1.0 to 2.0=

Crowd plugin 2.0+ uses the REST API provided by Crowd. The crowd url us=
ed in the configuration (crowd.url) must be the main URL of your crowd inst=
ance and not its /services/ end point (used with the previous SOAP integrat=
ion)

Cro=
wd plugin 2.0+ synchronises groups from Crowd thus take care to create a gr=
oup sonar-administrators in your Crowd directory and add in this group all =
users you'll want to use to administer SonarQube. You can also define some =
accounts to not synchronise with the property sonar.security.localUsers

Deprecated Crowd plugin 1.0 configur=
ation

Make sure that at least one user with System administration role exists=
in SonarQube as well as in the external system

Update the SONARQUBE_HOME/conf/sonar.properties file by add=
ing the following lines:

SONARQUBE/_HOME/conf/sonar.properties

=20

# Activates the plugin. Leave blank or comment out to use defa=
ult SonarQube authentication.
sonar.authenticator.class: org.sonar.plugins.crowd.CrowdAuthenticator
# Ignore failure at startup if the connection to external system is refused=
.
# Users can browse SonarQube but not log in as long as the connection fails=
.
# When set to true, SonarQube will not start if connection to external syst=
em fails.
# Default is false.
#sonar.authenticator.ignoreStartupFailure: true
# Automatically create users.
# When set to true, user will be created after successful authentication, i=
f doesn't exists.
# The default group affected to new users can be defined online, in SonarQu=
be general settings. The default value is "sonar-users".
# Default is false.
sonar.authenticator.createUsers: true
# URL of the Crowd server (usually ends with /services/).
crowd.url:
# Crowd application name.
# Default is 'sonar'.
#crowd.application:
# Crowd application password.
crowd.password: