After upgrade to Sonarqube developer version 8.4 SAML is broken

SonarQube Server / Community Build
,
1

SAML settings are working good on developer version 8.2 and after upgrade to 8.4 resulting the following error:
You’re not authorized to access this page. Please contact the administrator.

Reason: The response was received at http://sonar-gtcoe.use1.sqa.aws.asurion.net:9000/oauth2/callback/saml instead of https://sonar-gtcoe.use1.sqa.aws.asurion.net/oauth2/callback/saml

Note - SAML settings was working from version 7.8 to 8.2, I don’t think so any settings issue

Also can’t revert back to version 8.2, SonarQube stopped working, log as below:
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
2020.07.30 19:53:34 INFO app[o.e.p.PluginsService] no modules loaded
2020.07.30 19:53:34 INFO app[o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
2020.07.30 19:53:51 INFO app[o.s.a.SchedulerImpl] Process[es] is up
2020.07.30 19:53:51 INFO app[o.s.a.ProcessLauncherImpl] Launch process[[key=‘web’, ipcIndex=2, logFilenamePrefix=web]] from [/opt/sonarqube/sonarqube-8.2.0.32929]: /usr/lib/jvm/java-11-openjdk-11.0.7.10-4.amzn2.0.1.x86_64/bin/java -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/opt/sonarqube/sonarqube-8.2.0.32929/temp --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED -Xmx512m -Xms128m -XX:+HeapDumpOnOutOfMemoryError -Dhttp.nonProxyHosts=localhost|127.|[::1] -cp ./lib/common/:/opt/sonarqube/sonarqube-8.2.0.32929/lib/jdbc/postgresql/postgresql-42.2.8.jar org.sonar.server.app.WebServer /opt/sonarqube/sonarqube-8.2.0.32929/temp/sq-process4649800968473646926properties
2020.07.30 19:54:00 INFO app[o.s.a.SchedulerImpl] Process[web] is stopped
2020.07.30 19:54:00 WARN app[o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 143
2020.07.30 19:54:00 INFO app[o.s.a.SchedulerImpl] Process[es] is stopped
2020.07.30 19:54:00 INFO app[o.s.a.SchedulerImpl] SonarQube is stopped
← Wrapper Stopped

2

Hello,

In the Upgrade Notes of SQ 8.4 there is a special note about SAML:

Additionnal SAML checks
SAML authentication adds additional checks for validating SAML responses from the identity provider. This could reveal a non-standard configuration that needs to be updated. Information will appear in the logs upon a failed login attempt in the event that the configuration needs to be tweaked.

Alex

3

Here is the error from web logs, what is that meaning & how to fix these errors. My setup is not using any ALB, I am just redirecting http traffic https for SAML.

2020.07.31 19:42:20 ERROR web[AXOmY7X2Sc5WvvRaAABq][c.o.s.a.SamlResponse] The response was received at http://sonar-xxx.use1.sqa.aws.xxx.net:9000/oauth2/callback/saml instead of https://sonar-xxx.use1.sqa.aws.xxx.net/oauth2/callback/saml
2020.07.31 19:42:20 ERROR web[AXOmY7X2Sc5WvvRaAABq][c.o.saml2.Auth] processResponse error. invalid_response

4

Any fix for this issue, not configured ELB. SonarQube hosted on AWS linux instances and using apache2 redirecting the traffic to https by using the below config (this was working from SonarQube developer edition 7.8 to 8.2):
<VirtualHost *:80>
ServerName
RewriteEngine on
Redirect / https://

<VirtualHost *:443>
ServerName
SSLEngine On
SSLProxyEngine On
SSLCertificateFile /etc/httpd/ssl/server.crt
SSLCertificateKeyFile /etc/httpd/ssl/server.key

SSLProxyVerify none
ErrorLog /var/log/httpd/test_ssl_error.log
CustomLog /var/log/httpd/test_ssl_access.log combined
ProxyPass / http://<hostname>:9000/
ProxyPassReverse / <hostname>:9000/
RequestHeader set X_FORWARDED_PROTO "https"
RequestHeader set X-Forwarded-Port "443"
5

This issue is resolved

1 Like
6

@rajks How did you resolve this? I’m facing the same issue.

7

For those struggling with this issue, our solution was to change the recipient and destination URLs on the IDP side to match the non HTTPS URL, the post is still sent to the HTTPS endpoint so the traffic is secure but inside the actual SAML assertion the intended target is the HTTP/Port 9000 URL. For those using Okta:

image
image747×355 24.1 KB

1 Like
8

it worked for us. thanks!!!