SSO sonar-scanner issue

Hi There,

I’m setting a new instance of Sonarqube and trying to integrate it with our SSO system. It’s all basically working until I attempt to run a sonar-scanner job.

sonar-scanner attempts to get the url :

Even passing a token along, sonar kicks back a “401 Unauthorized”.

As soon as I set sonar.web.sso.enable=false

Then sonar-scanner works again.

When sso.enable is set to false, it seems that url is publicly available with no authentication needed. When it is set, I seem to only be able to access the url directly via my web browser.

Any advice or suggestions?

Hi Jason,

Do you see the request make it to SonarQube’s access.log ? or does the 401 come from the reverse-proxy handling authentication ?

If latter case, you would have to double-check proxy’s behaviour wrt authentication (and potentially how it handles token-based auth coming from scanner).

It’s definitely the sonarqube sending the 401.

I initially had just that URL configured to bypass auth, then to be sure I disabled all auth on the proxy side.

The only thing that makes that url available or not is the sso setting in the config file. It’s as if turning on sso in the config causes sonarqube to stop accepting the token…

The more vexing part for me, is that URL is publicly available without any token or auth when sso is disabled.

Hi Jason,

I quickly enabled sso on an instance I had running (v7.2.1, only in the config, without any of the proxy infra), and still was able to run an analysis using a User Token. I think you’re in for some further digging here:

  • use reqAttribute{LOGIN} trick mentioned in to log the username of authenticated requests in access.log
  • understand which user is seen when you manage to open that URL via browser
  • understand which user is seen when you manage to run a scan
  • check what’s logged when your scanner execution fails
  • if still mysterious, you could consider sniffing some of the inbound traffic

Basically focus troubleshoot on the incoming request in SonarQube, and how its seemingly authenticated.

I ran into the same issue with /api/settings/values.protobuf returning a HTTP 401 error, despite /api/authentication/validate returning {"valid":true} with the same token. The reqAttribute{LOGIN} was showing up as - in the access.log.

Turns out Apache was sending a X-Forwarded-User: (null) header with the (whitelisted) API requests that were missing a SSO session, and those invalid SSO headers were confusing SonarQube. Fixing the Apache configuration to not send any X-Forwarded-User SSO header for the token-authenticated calls fixed the issue.