Missing ability to create SonarQube 'remote' users programatically use REST API

[Paul Wagland]

We are looking at rolling SonarQube out in our organisation, and to that end it would be useful to be able to assign issues to people. However, the issue can (logically!) only be assigned to users that exist. That's fine, we have an API for that, for example: https://sonarqube.com/web_api/api/users

However, we also use the LDAP plugin to authenticate against ActiveDirectory, we can't use the ActiveDirectory plugin, since the service runs on linux, and the AD plugin is Windows only.

That means that all of the users are created need the is_local flag to be false. However, when I create the user using https://sonarqube.com/web_api/api/users/create, that flag is always set to be true, and I have no option to override it.

It would be very convenient if there was a way to be able to create the user automatically, so that this could be added as part of the boarding tasks of IT.

[Julien Lancelot]

Hi Paul,

What's the issue to have users marked as local ? LDAP users will always be marked as local, because from a user point of view, the authentication is done from SonarQube, not from an external provider (for instance, with the SonarQube GitHub Auth plugin, the authentication is done by GitHub, that's why users won't be marked as local).

Regards,

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/cb67d54c-7a49-4048-b8c3-6a835fe50956%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Julien LANCELOT | SonarSource

http://sonarsource.com

[Julien Lancelot]

Sorry, in fact you're right, LDAP users are not marked as local (I've mixed with the external_identity_provider column that will be 'sonarqube' for LDAP users but 'githib' gor GitHub users).

And I really don't like the idea to create user on the fly when assigning issues on unknown users.

Regards,

[Paul Wagland]

That is not true, a user imported from LDAP is not marked as a local user:

sonar=# select id,login,external_identity_provider,user_local from users;

 id |    login     | external_identity_provider | user_local

----+--------------+----------------------------+------------

  2 | pwagland     | sonarqube                  | f

  1 | admin        | sonarqube                  | t

As you can see, admin has 'user_local' 't', I have it as 'f'. If that value is 't' then it will always use the local password stored in SonarQube, meaning that you cannot use the password from AD anymore. If I try to create this user with the web-api, then that flag is always 't', and cannot be changed, short of connecting directly to the database. Additionally, I also have to provide a password, which I don't want, since it shouldn't be used anyway.

Cheers,

Paul

[Paul Wagland]

FWIW, I do not want to create users on the fly. I want to be able to pre-create them, for example as part of the on boarding process. At this point in time we can correctly set the name, email, and user id.

If the user does not exist, then I do not want the user created as part of the scan.

Cheers,

Paul

[nicolas...@sonarsource.com]

Hi Paul,

Indeed, the current 'per-design' behaviour is that an LDAP/AD user is populated into SonarQube database +only+ when this users attempts to connect to SonarQube (no way to pre-provision it). While that might sound bothering in your case, think back about the use-case:

• 'correctly set the name, email, and user id' : this shouldn't require manual intervention, the point of the LDAP Plugin is to have the correct information automatically synched down from LDAP/AD server (see documentation , with properties such as ldap.user.realNameAttribute or ldap.user.emailAttribute )

• groups/permissions management in SonarQube: sounds tedious because indeed the user does not exist in SonarQube until he logs in. However the right solution to that problem is to actually leverage the LDAP Plugin at its full potential: use the Group Mapping functionality. You centrally manage group membership in your LDAP/AD server (where your full set of users is also visible) and that info is then automatically synched-down to your SonarQube server (note that only groups that have been created in SonarQube are used for group mapping).

The idea is to simply remove the need for any onboarding at all in SonarQube (e.g. done by IT). Newcomers are centrally onboarded in LDAP/AD, with all the accurate info and groups, and then SonarQube simply inherits everything. "Less is more" :)

Best regards,

Nicolas

[Paul Wagland]

Hi Nicolas,

Indeed, and all of what you described works perfectly! Assuming that the user actually logs in at some point in time. If they don't login, then the user is (obviously) not created. If the user is not created, then I cannot assign an issue to them, nor can it be assigned automatically. This leads to the perverse incentive that it is better to not login to the system, since until you do, none of the issues can be assigned to you!

We have seen this across a number of our systems. For example, until they log into the issue tracker, you can't assign them any issues. Because of this, we try to pre-emptively create the users in the on boarding script. This way, they still only have one username/password to remember, disabling one account still disables the ability to login to everything, but managers can start assigning things before the person starts.

In my particular use case, I don't want to have to chase people up to get them to login just so that they can be assigned the SonarQube issue… I want that to happen automatically.

Cheers,

Paul