How-to transfer an account to a different authentication method

SonarQube Server / Community Build
,
1

Hi,

  • I am the administrator of a SonarQube enterprise instance (version 8.9.3) and try to setup our internal GitLab instance as SSO.
  • Right now we use the same LDAP tree for authentication in both SonarQube and GitLab.
  • I now managed to setup the integration of GitLab and SonarQube ALM basically, however am struggeling with the issue in the summary.
  • Whenever an existing user is trying to login via GitLab, they get the message:

You’re not authorized to access this page. Please contact the administrator.
Reason: This account is already associated with another authentication method. Sign in using the current authentication method, or contact your administrator to transfer your account to a different authentication method.

How do I transfer the account? I did not find hints in the documentation.

Thanks for any answers
Mirko

1 Like
2

Hey @mfriedenhagen

Checkout this Community Guide. It should be a helpful starting point.

3

Hi @Colin,

thanks for the link, definitely helpful.

Maybe you could adapt the wording in the error message? When I search for “migrate sonarqube authentication” I now get a link to https://docs.sonarqube.org/latest/instance-administration/delegated-auth/ which I missed before.

The error message speaks of “transfer” instead of “migrate” and so just “googling” for the error message did not help me :slight_smile:.

Best Regards
Mirko

4

Hi @Colin, coming back here:

  • Unfortunately the user-ids I get via the GitLab integration are completely different from ones I had before via LDAP.
  • It seems SonarQube uses a concatenation of the first- and lastname where any non-ASCII characters are stripped together with a random integer as login.
  • In our LDAP we generally have first-character-firstname + lastname as login.
  • After I had transfered/migrated my user I was unable to login at all, neither GitLab nor LDAP did succeed.
5

Coming back to this:

  • It is very important not to deactivate an account, then a fresh account with the new login is created.
  • If you did this, you need to deactivate the new account and recreate the old one with old login with api/users/create again.
6

Hi Mirko,

We are converting user from SAML to Gitlab authentication and facing issue with login. Did you find any solution for your issue?

7

Well, you need to look into the user object:

curl -u ${adminToken}: -s https://sonarqube.example.com/api/users/search -d q=tony.curtis@example.com | jq
{
  "paging": {
    "pageIndex": 1,
    "pageSize": 50,
    "total": 1
  },
  "users": [
    {
      "login": "tcurtis",
      "name": "tony curtis",
      "active": true,
      "email": "tony.curtis@example.come",
      "groups": [
        "legacy-developers",
        "sonar-users"
      ],
      "tokensCount": 4,
      "local": false,
      "externalIdentity": "tcurtis",
      "externalProvider": "oidc",
      "avatar": "f5c40f9af1a05ae39325ccdaeb61196d",
      "lastConnectionDate": "2022-08-26T14:37:25+0200"
    }
  ]
}

Important is the externalProvider entry here. You may update the user like this:
curl -u ${adminToken}: -s https://sonarqube.example.com/api/users/update_identity_provider -dlogin=tcurtis -d newExternalProvider=gitlab (I just guessed the name gitlab here)

If the identity in GitLab is different from the one in SAML/OIDC you may need to a parameter newExternalIdentity needs to be added.

There is an externalProvider called sonarqube which does use either LDAP or the internal password mechanism of sonarqube.

8

Hi, I made migration from OIDC to gitlab as it was described above. But I have the same error. Logs in debug mode says my that email is already in use… Of course it’s in use. I have the user with this email and I want to change authentication from openID to gitlab… Maybe someone had such problem, when you did migration through API, but it’s still doesn’t working?

{
“paging”: {
“pageIndex”: 1,
“pageSize”: 50,
“total”: 1
},
“users”: [
{
“login”: “53306”,
“name”: “Name Of the User”,
“active”: true,
“email”: “my_email@mydomain.com”,
“groups”: [
“some groups”
],
“tokensCount”: 2,
“local”: true,
“externalIdentity”: “my_email@mydomain.com”,
“externalProvider”: “gitlab”,
“avatar”: “f3ee6”,
“lastConnectionDate”: “2023-06-27T11:44:19+0300”
}
]
}

9

Hi @ahgpeu,

we recently switched all users from LDAP to SAML using the API call as outlined above and that did succeed. We defined a local admin user and used that one to change all entries (in our case we have SAML with 2FA which is used for humans and still use LDAP for so called service accounts used during CI which are able to login via basic auth).

10

Thank you for an answer. Tell me please, you just call for every account something like this:
curl -X POST -v -u XXX_local_admin_token_hereХХХ: “https://my_domain.com/sonarqube/api/users/update_identity_provider?login=53306&newExternalProvider=gitlab”
Keep users email as is and just login with account with other external authentication provider?
No user deactivation, no changing fields in sonarqube db, no other magic tricks? If so, it defenetly doesn’t work in my case… I tried change auth provider both api-way and changing db fields… No result…
2023.09.27 17:39:50 DEBUG web[AYYdfdds544gfdSSddf44][auth.event] login failure [cause|Email ‘user.name@mydomain.com’ is already used][method|OAUTH2][provider|EXTERNAL|GitLab][IP|127.0.0.1|][login|xx.username]

11

Hi @ahgpeu,

  • Yes, that curl-request of yours was basically it.
  • However, in our case the old login with LDAP and the externalIdentity with SAML are identical, so we just did added newExternalIdentity=${login} in the POST.
  • Maybe you need to update the login afterwards? There is api/users/update_login as well.
12

Thank you all for the responses. My issue has been solved. In addition to changing ExternalProvider to ‘gitlab’, it was necessary to update ExternalIdentity for users to their GitLab user IDs. So to work with API string is: curl -X POST -v -u $SonarAdminToken: “https://sonarqube.url/sonarqube/api/users/update_identity_provider?login=$SonarqubeLogin&newExternalIdentity=$GitlabUserId&newExternalProvider=gitlab”

13

For me it also took a bit of time to understand that I have to update the ExternalIdentity field as well.
Using the api 2 version, this call worked for me:

curl -X PATCH -u <USER_TOKEN>: '<SONAR_URL>/api/v2/users-management/users/ 
<ID-OF-USER>' -H 'Content-Type: application/merge-patch+json' -d '{"externalProvider": "saml", "externalLogin": "<MAILADDRESS>", "externalId": "<MAILADDRESS>"}'