Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup
{iframe:src=http://update.sonarsource.org/plugins/ldap-confluence.html|width=700|height=250300|frameborder=0}
Your browser does not support iframes.
{iframe}

...

  • 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 or and the internal authentication systems (for instance, technical SonarQube user accounts do not need to be defined in LDAP as there is an automatic fallback on SonarQube engine if the user is not defined in LDAP or if the LDAP server is down).

During the first authentication trial, if the 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 already defined in SonarQube are automatically refreshed in the SonarQube database. For the delegation of authorization, groups and related permissions must be first defined in SonarQube.

Requirements

 

Apache DS

OpenLDAP

OpenDS

Active Directory

Anonymous

(tick)

(tick)

(tick)

 

Simple

(tick)

(tick)

(tick)

(tick)

LDAPS

(tick)

(tick)

 

(tick)

DIGEST-MD5

(tick)

 

(tick)

(tick)

CRAM-MD5

(tick)

 

(tick)

(tick)

GSSAPI

(tick)

 

 

 

...

  1. Configure the LDAP plugin by editing the SONARQUBE_HOME/conf/sonar.properties file (see belowtable 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

Anchor
Configuration
Configuration
General Configuration

PropertyDescriptionDefault valueMandatoryExample
sonar.security.realm

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 SonarQube internal system.

None

Yes

LDAP (only possible value)
sonar.security.savePassword
To save the user password in the SonarQube database. Then, users will be able to log into SonarQube even when the LDAP server is not reachable.
false
No 
sonar.authenticator.createUsers

By default, the SonarQube database is automatically populated when a new user logs into SonarQube. Setting this value to false, makes it mandatory for a System administrator to first declare a user through the SonarQube web interface before allowing this user to log into SonarQube.

true
No 
sonar.security.updateUserAttributes

If set to true, at each login, user's attributes (name and email) are re-synchronized. If 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 SonarQube 3.6.

true
No 
sonar.authenticator.downcaseSet to true when connecting to a LDAP server using a case-insensitive setup.falseNo 
ldap.url
URL of the LDAP server. Note that if you are using ldaps, then you should install the server certificate into the Java truststore.None

Yes

(Not mandatory in case of Auto-discovery)

ldap://localhost:10389
ldap.bindDn
Bind DN is the username of an LDAP user to connect (or bind) with. Leave this blank for anonymous access to the LDAP directory.NoneNocn=sonar,ou=users,o=mycompany
ldap.bindPassword
Bind Password is the password of the user to connect with. Leave this blank for anonymous access to the LDAP directory.NoneNosecret
ldap.authentication
Possible values: simple | CRAM-MD5 | DIGEST-MD5 | GSSAPI
See http://java.sun.com/products/jndi/tutorial/ldap/security/auth.html
simpleNo 
ldap.realm
NoneNoexample.org
ldap.contextFactoryClass
Context factory class.com.sun.jndi.ldap.LdapCtxFactoryNo 

User Mapping

PropertyDescriptionDefault valueMandatoryExample for Active Directory Server
ldap.user.baseDnDistinguished Name (DN) of the root node in LDAP from which to search for users.None

Yes

(Not mandatory in case of Auto-discovery)

cn=users,dc=example,dc=org
ldap.user.request

LDAP user request.

Available since version 1.2.

(&(objectClass=inetOrgPerson)(uid={login}))
No
(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttributeAttribute in LDAP defining the user’s real name.cnNo 
ldap.user.emailAttributeAttribute in LDAP defining the user’s email.mailNo 

Group Mapping

The following properties should Only groups are supported (not roles). Only static groups are supported (not dynamic groups).

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.

There are two limitations:

  • Groups must be static and not dynamic
  • The user entry must contain the attribute memberOf with the list of groups
PropertyDescriptionDefault valueMandatoryExample for Active Directory Server
ldap.group.baseDnDistinguished Name (DN) of the root node in LDAP from which to search for groups.NoneNocn=groups,dc=example,dc=org
ldap.group.request

LDAP group request.

Available since version 1.2.

(&(objectClass=groupOfUniqueNames)(uniqueMember={dn}))
No
(&(objectClass=group)(member={dn}))
ldap.group.idAttributeAttribute in LDAP defining the group's id.cnNo 

Example of LDAP Configuration

Code Block
languagebash
# LDAP configuration
# General Configuration
sonar.security.realm=LDAP
sonar.security.savePassword=true
ldap.url=ldap://myserver.mycompany.com
 
# 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 Configuration

Include Page
Include - Technical Users
Include - Technical Users

Mutliple Servers

Available since version 1.3.

To configure multiple servers:

Code Block
languagebash
# 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.sever2.url=ldap://server2:1389
ldap.sever2.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

 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.

Anchor
Auto-discovery
Auto-discovery
Auto-discovery

...

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

Troubleshooting

You For versions prior to SonarQube 4.1, you can enable debug logging by adding the following to SONARQUBE_HOME/conf/logback.xml:

Code Block
titleconf/logback.xml
<logger name="org.sonar.plugins.ldap">
  <level value="DEBUG"/>
  <appender-ref ref="CONSOLE"/>
  <appender-ref ref="SONAR_FILE"/>
</logger>

Change Log

JIRA Issues
anonymoustrue
titleVersion 1.3
height50
renderModestatic
width900
columnstype;key;summary;priority
urlhttp://jira.codehaus.org/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?fixfor=19024&pid=11911&sorter/field=priority&sorter/order=DESC&tempMax=1000

 

JIRA Issues
anonymoustrue
titleVersion 1.2.1
height50
renderModestatic
width900
columnstype;key;summary;priority
urlhttp://jira.codehaus.org/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?fixfor=18856&pid=11911&sorter/field=priority&sorter/order=DESC&tempMax=1000

 

JIRA Issues
anonymoustrue
titleVersion 1.2
height50
renderModestatic
width900
columnstype;key;summary;priority
urlhttp://jira.codehaus.org/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?fixfor=18454&pid=11911&sorter/field=priority&sorter/order=DESC&tempMax=1000