Update ExternalProvider using API

SonarQube Server / Community Build
1

Hello,

While currently using version 10.8 EE were working on upgrading toward the newer 2025 version of SonarQube.
One of the actions we need to perform to update our authentication.

In the config file we enabled SSO header authentication.
For a new account it is working as expected, for existing accounts however we get “This account is already associated with another authentication method.”

On the test user we notice that the ExternalProvider was set to sonarqube, where existing accounts are set to aad.

While we tried to change the newExternalProvider=sonarqube, the account is set to LDAP_Default

We used the following two options; were we think the API v2 is the way to go.

We can’t set the newExternalProvider=sonarqube, however, as we get “ {“message”:“Unsupported media type.”} ” as error.

While using

we get:

  • {“message”:“Invalid request format.”}curl: (3) unmatched brace in URL position 2:
    '{externalProvider:
    ^

To us it looks like the externalProvider is not available to set, but a new user is getting this value set however upon a successful login.

Any hints are welcome here,

Thanks in advance,
Bas

Already one other question, any option do this as a mass action on all existing accounts?

We can get all ID’s using “curl -X GET -u TOKEN: http://localhost:9000/api/v2/users-management/users” but then we need to perform a lot of manual action to set the provider on each account.

2

Hey @BasANow,

Even after fixing your curl command:

curl -X PATCH -u TOKEN: "http://localhost:9000/api/v2/users-management/users/ID" \
     -H "Content-Type: application/merge-patch+json" \
     --data '{"externalProvider": "sonarqube", "externalLogin": "admin", "externalId": "admin"}'

I still encounter the following error:

<RestError><message>Value of 'externalProvider' (sonarqube) must be one of: [] or [LDAP, LDAP_{serverKey}]</message></RestError>

It seems not possible to set the identity provider to sonarqube, which is what is expected for HTTP Header Auth.

So, I’m uncertain how to use our APIs to migrate users to HTTP Header Auth at this point. I’ve highlighted this with the team for further investigation.

Out of curiosity, could you share a bit more about your use case for HTTP Header Auth? It’s fairly uncommon nowadays—most organizations seem to prefer SAML for authentication.

4

Hi Colin,

Thanks for checking the curl command, but sorry to see that it’s also not working at your side.

the reason we want to switch to the HTTP header auth is that we use a reverse proxy where the redirect URL of the SAML redirects to the public endpoint where SQ expects the server FQDN.

This is an issue till were moving to SonarCloud.

Regards,

Bas

5

Although I haven’t touched SAML auth for a while, I’m not convinced this isn’t something you can overcome. I’ve written some guides on the topic.

Have you considered making a seperate topic about this?