Issues with Gitlab authentication without deleting existing user account

SonarQube
, ,
1
  • SonarQube 9.9 LTS
  • Gitlab 15.11 (self-hosted)
  • Installed with zip file
  • Enable Gitlab auth or, failing that, SAML auth

I have everything working EXCEPT that in order to successfully log in to SonarQube with Gitlab, I must first delete the local user account within SonarQube.

I’ve found other posts on this topic, but the suggested API commands in those threads do not work, possibly due to version differences.

Here’s where I’m at right now:

If I attempt to log in as an existing user, I get the error:

You’re not authorized to access this page. Please contact the administrator.
Reason: Failed to authenticate with login ‘username’

‘username’ in this case is a placeholder for the real user name. However, if I delete that user from SonarQube, I’m able to log in normally with no issues. Obviously I’d rather not delete all existing users and groups.

I’ve tried running curl -X POST -u $TOKEN: 'https://sonarqube.test.com/api/users/update_identity_provider?login=USERNAME&newExternalProvider=gitlab&newExternalIdentity=USERNAME@DOMAIN>COM

as recommended elsewhere but this does not change the behavior. Additionally, both SQ and Gitlab currently integrate with the same internal LDAP server so I wouldn’t expect a field mismatch that the above command is presumably intended to resolve.

It seems like I’m very close to getting this working, but I don’t know how to inspect what information Gitlab is sending or how to tell how that information differs from what SonarQube expects.

Any assistance would be appreciated, I’m not exactly an expert with SonarQube itself or with this sort of authentication setup.

2

Hi,

Welcome to the community!

Can you run api/users/search for one user who still can’t log in, and one user who can, and compare/contrast the results? Specifically, I’m wondering if there are differences in (format for) externalIdentity, externalProvider or anything else of significance.

 
Ann

3

Hi, Ann -

Thanks for the reply.

There isn’t an obvious difference between users who can, and users who cannot log in.

However, I managed to find another post that specifically referenced mapping the Gitlab user ID to the SonarQube user ID, and that resolved the issue for me:

curl -X POST -u $SONAR_TOKEN: 'https://sonarqube.test.com/api/users/update_identity_provider?login=$SQ_username&newExternalProvider=gitlab&newExternalIdentity=$GL_USER_ID

where SONAR_TOKEN is a valid SonarQube API token, SQ_USERNAME is the current user name shown in SQ, and GL_USER_ID is the NUMERIC user ID shown on the user’s profile page in Gitlab.

1 Like