Potential workaround: Temporarily (cannot use for long term) - Create tokens for users or give them a direct SonarQube account
So, we received this error with both nginx and IIS reverse proxy scenarios. They both produce the same result. Version 8.2 and 8.3 work fine.
Documentation at SonarSource does not state what exactly changed with ADFS for v8.4. There are no additional configurations recommended. There does not appear to be any guidance period–my assumption is that this was an unanticipated issue from an ADFS security fix.
I’m hoping not to get the “non-standard configuration” reply…this is not the case. Guidance was followed as provided by SonarSource and we were working fine. A minor upgrade (8.x) should not have broke anything like this. I’m hoping that SonarSource can expose a configuration parameter or option or at least tell us how we can resolve this…
Hi Ann, I’ve exhausted the current threads–unfortunately, no resolution. It really appears to be an unintended result of a recent change. As I conveyed to @julienlancelot, I really wish there were a configuration item/flag or something to opt-out of this “security” change. I hadn’t seen this version pushed to GitHub yet, I’m looking forward to seeing the changes.
So @ganncamp and @julienlancelot, thinking through this, the AD FS (or even AAD) callback endpoint is configured here (see image) [we used: https://[fqdn]/oauth2/callback/saml].
Although, we can come back later in a dialog box to add another endpoint, it does not (and would not be wise for obvious security reasons) for us to add an http version of this, http://[fqdn]/oauth2/callback/saml. Yet, this is what the error seems to say. Our backend endpoint is configured to http://[fqdn]:9000/ and our sonar.core.serverBaseURL property is https://[fqdn]. So, if anything, it seems that our response that is received would have been something like, http://[fqdn]:9000/oauth2/callack/saml instead of what we see in the error message below:
You’re not authorized to access this page. Please contact the administrator.
Reason: The response was received at http://[fqdn]/oauth2/callback/saml instead of https://[fqdn]/oauth2/callback/saml
So, I get it that you’re attempting to validate the validity of the endpoint, so that it’s not spoofed, but is there a way to do it without using the protocol as part of the comparison? Or have a configuration to allow the check or the protocol to be ignored? The system should realize that an http URI would be invalid (security wise) anyway, or is it (not sure of the intention or design)? Thoughts?
So, with IIS, the X_FORWARDED_FOR is HTTP_X_FORWARDED_FOR. IIS works perfectly with the ARR and Rewrite module for the Reverse Proxy and AD FS integration!
