How to pre-create users who will authenticate via an Identity Provider with SQ 8

Hi,

Is it possible to pre-create users who will be authenticate to SQ v8.2 CE via an Identity Provider?
I have failed to do it with both OpenID (with the Open ID Connect plugin) and Gitlab (with the pre-integrated plugin) Identity Providers.

Our goal is to create and manage users and permissions of SonarQube (among other tools) outside SonarQube.

With SQ 7.9 CE, we used to use the Web API (/api/users/create) to create a “non-local” user account that was linked to the Identity Provider account of the user when he logged in the first time in SQ.

With SQ 8.2 CE (and probably the fact that logins of Identity Providers account are auto-generated - cf. https://jira.sonarsource.com/browse/SONAR-12475 -), it looks like that a new account has to be generated when an user logs in for the first time in SQ.

The user creation Web API (/api/users/create) stills works the SQ 7.9 way: the login is still mandatory for a non-local user and it is returned as is when it should be auto-generated.

If an account is pre-created with the Web API with the email address of the Identity Provider user account, then, when he logs in SQ the first time, he is notified that his email address is used by the account pre-created and if he is asked if he wants to associate this email to a new account associated that will be created (with the loss of any permissions given to the pre-created account)

Finally, the creation of a new account during the first authentication makes it mandatory for users to be able to “sign-up” in SonarQube, although this remains an option of the different authentication plugins.

So I would like to know if it is still possible to pre-create an account that will be linked to an Identity Provider in SonarQube v8.2+ and how to do it if it is the case.

Thanks in advance.

I’m struggling with this issue myself: We’re maintaining our user identities in Keycloak. Our users are using the same login / username via SSO (OpenID Connect) in GitLab, Mattermost, Jira, … and (up to version 7.9) in SonarQube.

Unlike Gitlab’s REST API SQ’s Web API does not support the attributes externalIdentity and externalProvider while creating new users. So until SonarSource adds this kind of support, pre-creating externally managed users is not possible any more.

Hello @Rodolphe_Dariol and @tjuerge,

I confirm that it’s indeed not possible to create users in advance when using external authentication.

Could you please elaborate in which context you need this, and describe use cases ?

Thanks !

@julienlancelot Thanks for picking this up.

In our organisation the user identities are maintained in an IdP. All users have the same unique userid across all of our tools and authenticate automatically via SSO. During onboarding the users are getting their accounts (with corresponding permissions) pre-populated in all the tools they need according to their role.

So what @Rodolphe_Dariol and I are asking for is the ability to create (externally managed) users via SQ’s web API not only with SQ identity information (login, email and name) but also with the IdP information (attributes externalIdentity and externalProvider). With this information a user which authenticates in SQ via one of the SSO plugin is automatically associated with the existing pre-created user account.

From looking at the current implementation in org.sonar.server.user.ws.CreateAction this could be easily added: Introduce additional request parameters externalIdentity and externalProvider and use their values in doHandle() for populating the ExternalIdentity instance.

WDYT?

IMHO SQ’s current web API has a shortcoming - there’s no way to add or modify the user attributes externalIdentity and externalProvider - not in api/users/create or api/users/update or api/users/update_login. Only plugins can provide this information. And due to SONAR-12475 these plugins are not able to specify the user’s SQ login anymore.

Hi @tjuerge,

Thanks for your explanation, I’ve understood what you’re asking for, my question is about the why : why do you need to pre-create users before they authenticate ? What benefit will it brings to you ?

Thanks for your answer !

Hi @julienlancelot,

Thank you for your time.

In our organization, SonarQube’s projects have to be private by default and users will not be able to work on their projects once they are authenticated ; they would have to wait for the administrator of the project to give them the permissions to access to the project.

We would like to be able to pre-create their accounts and give them permissions so that they will be able to start to work once they authenticate.

And, as we provide a web portal to give IT development teams the accesses to the dev tools they may use to achieve their goals (tools as source code manager, bug trackers, etc.), it benefits project managers to ease them the management of their team members as giving them permissions from a centralized point instead of connecting on every tools to do this.

In order to add SonarQube in the tools supported by the portal, we need to pre-create users with the Web API to be able to give them permissions before they authenticate.
Otherwise, project managers will have to wait that users authenticate once before being able to give them the permissions to their projects.

Thank you.

In our IdP all user identities and their permissions in every tool are maintained. Using this information from the IdP the tools are automatically provisioned with all projects, groups, users, … There’s no administrator manually maintaining the corresponding settings in the various tools.

One benefit of this pre-flight onboarding is that we can assure our auditors that every user has in every tool exactly the permisions which are necessary for their role.

Thanks a lot @Rodolphe_Dariol, I understand what problem you’re trying to solve !

In order to resolve your issue, you have the Group Mapping feature, which allow you to specify in which group the user should belong when he will authenticate to SonarQube.

Dis you already tried it ?

Same situation here :slight_smile:
Without four-eyes approval nobody gets access to any tool.

How does Group Mapping help with our issue of externally managed users?

And what if no groups are involved because the users are added to the projects directly?

@julienlancelot,

We have not tried Group Mapping

I am not sure - correct me if I am wrong - but I have understood that it implies that the groups are managed at the Identiy Provider level and that they are provided by it as the same time as the identity of the user when he logs in SQ.

If I am right then it will be difficult for us to try it as our Identiy Provider does not provide any role information.

On the SonarQube side, I think that, like @tjuerge wrote, we would have to manage permissions at the group level instead of at the project level as we intended to.

We had looked quickly at the group management when we investigated how to manage user permissions in SonarQube and we had not picked it because:

  • it would mean that we would have to create at least a new group for a new project (depending on the permissions we set in groups),
    • or, maybe, better, at least a new group for each group of projects managed by a new product team,
  • we have planned to let the team the permission to administrate the project from SonarQube itself as it gives them the way to set some global analysis parameters but, on the other hand, it allows also them to manage directly the permissions of the users at the project level and we thought that it could be a mess for us and them to have permissions which come both from groups and projects.

Let me know if you think that there would be any changes about the creation of user accounts with the Web API.

If it won’t change, I think that we will ask our users to create their accounts by logging once in SQ before project administrators could give them permissions to the projects.

Thank you again for your support.

Hi @Rodolphe_Dariol,

Indeed, the goal of using Group Mapping is to delegate groups mapping to the Identity Provider.

Most of the time, it’s possible to use groups and bind them to projects (either manually or using permission template). Then you don’t have to specify permission user per user.

I understand that in your case, you prefer manage project permission user by user instead of using group, unfortunately it will force you to ask users to authenticate first on SonarQube, then to assign them permission.

Regards

Hi @julienlancelot,

I have another question about groups and permission template:

You wrote:

Most of the time, it’s possible to use groups and bind them to projects (either manually or using permission template).

I can’t see how you can bind a group of users to his project with permission templates.

If we achieve to use groups to manage permissions, I think that we will have, on the SQ side, each time a new project is created, to create at least one new group and to give it permissions to the project.
For example, we would have to create the “project1-users” group for the “project1” project.

And as these groups need to be created for a new project, I can’t see how they can be managed by the permission template.

The only “dynamic group” that can be managed by the permissions template is, for what I have understood, the “creator of a project”.

So the only way I can see to bind a group of users to his project is to do it “manually” or by the Web API.

What did I miss?

Thanks in advance.

Regards.


Rodolphe

It seems that this will be coming with SONAR-13930 Allow migration of authentication system.