We’ve been running SonarQube 8.0 for about a year using the SAML integration for auth (with CA Siteminder as our IDP). When trying to update to 8.7 recently, we saw this error on the ACS redirect from the IDP (names changed to protect the innocent):
Looking through other topics I see this is a fairly common complaint with 8.4+, and others have solved their issues by setting ProxyPreserveHost or similar. In our case there are actually (at least) two proxies involved (gotta love enterprise IT):
an in-house reverse proxy behind that public hostname’s IP that’s proxying the request to the backend hostname
OpenShift’s HAProxy router, which uses the backend hostname to map the request to the Kubernetes pod running SonarQube.
We can’t change proxy #1 to send the original public Host header, because proxy #2 is using the private hostname for its routing decisions, and we can’t (so far as I can tell) configure proxy #2 to change the Host back to the public one after it picks the right route.
As an experiment to confirm I understand what’s going on I bolted an nginx sidecar onto our SonarQube pod whose entire purpose in life is to act as YET ANOTHER reverse proxy (it’s proxies all the way down!) that just restores the public hostname in the Host header on its way to SonarQube, and that does indeed fix the problem. If all else fails this might be a viable temporary band-aid, but it pains me.
Looking through the sonarqube source I see this bit where it’s patching in the X-Forwarded-Proto to handle the https vs http fail-case I see referenced in other topics:
This method is cobbling together a faux request object that’s passed to the SAML lib that’s actually generating the error. What I’m wondering is if this can be additionally modified to swap the Host for the value, if present, of X-Forwarded-Host, or the host section of Forwarded.
Good idea, bad idea, entirely on the wrong track? Better/smarter/faster way of doing what I’m trying to do? Any suggestions appreciated!
Hello @jeff.powers
thanks for reaching out to the Community, and welcome!
Indeed, SonarQube SAML checks were strengthened on SonarQube 8.4+ and upgrades are known to cause some trouble with some proxy setups, troubles not always easy to work around.
So thanks for sharing sharing details about your proxy setup and your work around for it!
Our thanks as well for your suggestions about how to make it easier to manage with SonarQube. I’ll make sure we take your post into account for potential improvements.
Side question as I’m not familiar with the OpenShift HAProxy particularities: do you have any possibility to rewrite the URL itself as is possible with set_uri on standard HAProxy instances?
Not that I’m aware of; in this case the HAProxy pods aren’t directly configured by us, they’re managed by OpenShift which builds their configuration dynamically based on Route/Ingress objects added to the cluster. They have a limited set of annotations you can define on these to modify the routing behavior, such as altering the default timeout, but apparently not one for rewriting the host:
