How-to transfer an account to a different authentication method

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

Hey @mfriedenhagen

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

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

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.

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.

Hi Mirko,

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

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.