SonarQube upgrade to 2025.1.0 impacting SAML Okta authentication

SonarQube Server / Community Build
1

I have initially SonarQube version 10.6.0 deployed using Helm chart on EKS cluster on AWS.
Upon upgrading to the latest version of SonarQube 2025.1.0, the upgrade went well except for the SAML authentication using Okta. Using the admin account to test the connection, I have this error raising:

Error:
Invalid destination [https://sonar.company.io/oauth2/callback/saml] for SAML response.

I had to rollback to the previous version to have SonarQube stable again, and it is working fine. Note that between the upgrade and the rollback, nothing has changed on the Okta application.

Thank you,
Oumayma.

2

Hey there.

Thanks for raising this.

We had to pretty substantially update our SAML implementation before releasing 2025.1.0, so it’s a little scary to see an issue like this pop up! Hopefully, there’s just a small configuration issue somewhere.

Once upon a time, we would have told you what the valid destination was. Now that information is buried in DEBUG level logs.

Ideally, you would upgrade a copy of your production instance and turn on DEBUG logs (global Administration > System > Log Level) and check the web.log file to compare the expected recipment to the valid recipient.

2025.02.12 10:36:31 DEBUG web[791691a4-1ac7-4967-8346-46f819dd360b][o.o.s.s.a.i.AbstractSubjectConfirmationValidator] Evaluating SubjectConfirmationData@Recipient of : https://example.ngrok.app/oauth2/callback/saml
2025.02.12 10:36:31 DEBUG web[791691a4-1ac7-4967-8346-46f819dd360b][o.o.s.s.a.i.AbstractSubjectConfirmationValidator] Matched valid recipient: https://example.ngrok.app/oauth2/callback/saml

The discrepancy between these two URLs would be the first clue to what’s going on.

3

Hello Colin,

Thank you for your response!
Exactly, upon checking the logs, I found that the recipient URL diverge:

Failed to match SubjectConfirmationData@Recipient to any supplied valid recipients: [http://localhost:9000/oauth2/callback/saml]

I fixed this issue by overriding the property Server base URL under Administration > Configuration > General > General in the UI with the current URL of our SonarQube.

If the deployment is done via Helm chart, it can be overridden like below (via the config map):

sonarqube:
  sonarProperties:
    sonar.core.serverBaseURL: "https://sonar.company.io/"

I suggest to add this information to the upgrade release, as it can create a breaking change when upgrading versions, especially when in previous versions we were not used to override this property.
Oumayma.

4

Thanks!

You know, I tried to reproduce this situation, but Microsoft Entra blocked me from even authenticating while it was not set (and I think it has always been this way), so I don’t think you would have reached the error message you did if sonar.core.serverBaseURL wasn’t set.

Since it seems we might be stricter than before, I’ll ping our Docs folks. Maybe it’s worth an upgrade note.

15

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.