How-to transfer an account to a different authentication method

SonarQube
,
#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.