Sonarqube - Developer 8.4.0.35506 - SAML error "[c.o.s.a.SamlResponse] <sonar.auth.saml.applicationId> is not a valid audience for this Response"

SonarQube Server / Community Build
,
1

Hello team,

Being a good internet citizen and creating a ticket in case this is of use for the developers at Sonarqube, or others who bump into the same error.

In our case, we are using Microsoft Azure Active Directory App Registrations to enable login to Sonarqube via our corporate system.

  • Affected version: Developer 8.4.0.35506
  • Errors observed: While logging into Sonarqube via SSO, the user is navigated to the appropriate login screen on Microsoft, authentication is provided, and the user is redirected back to Sonarqube. At this point the following message is presented: “<sonar.auth.saml.applicationId> is not a valid audience for this Response”. Where “sonar.auth.saml.applicationId” is the GUID specified within Administration > Configuration > Security > “Application ID”. This application ID was retrieved, in our case, from Azure AD > App registrations > (the configured application by our Corporate IT team) > Application (client) ID.
  • Investigation: We set the logging within Sonarqube to it’s highest level within Administration > System > Logs Level (TRACE), and then downloaded the logs. Within the logs there is the actual SAML response and a node called <AudienceRestriction><Audience>XXXXX</Audience></AudienceRestriction>. At this point, interestingly we saw the text “spn:” within the node, preceding the expected SAML Application ID GUID.
  • Workaround: By updating the Sonarqube SAML Application ID to be exactly the same string, including “spn:”, within the node from the logs, we were able to successfully log in via SAML. Location of setting in Sonarqube is Administration > Configuration > General Settings > Security > Application ID. (see image below)

SAML configuration
SAML configuration1298×777 28.7 KB

I have a feeling this is a bug introduced in release 8.4 as we have another system running an older version (8.1), which is not affected by this issue despite having the same SAML configuration. This may have been included in the release / upgrade notes between version 8.1 and 8.4, however I was unable to find a reference to this, so decided to raise this ticket / issue in case it’s of use to others.

As we speak, there was an updated version released on the 15th of July 2020 (8.4.1), however the release notes do not mention this particular issue, so we will continue our upgrade to release 8.4.0 with this known workaround and upgrade to the newer version on our next patching cycle.

Hope this is of use to somebody,

Cheers,
Sean

3

Hi,

There were indeed a change in the way SAML authentication is validated. We didn’t think it would have such impact, that’s the reason why you couldn’t see anything in the release notes.

It seems that before 8.4, the application ID was not really used to do the authentication. I would be interested to know if a random value was used in 8.3 would have made the authentication failed…

Anyway, thanks for sharing how you’ve fixed this, it would definitely help other users!

Regards,
Julien Lancelot

4

I have a similar issue Julien (good name btw–same as my grandson’s).

I have the correct Sonarqube SAML Application ID. It worked in 8.2 because if I changed it to anything other than the correct one, I would get an AD FS error message saying that it did not exist on the SP.

So, I’m really struggling why a minor push, is causing a breaking issue like this. I don’t see the code pushed out to GitHub yet, so I can’t take a look to see what I might be missing (configuration wise) on our end (if that’s the case).

You and your team have been doing great work. Hopefully this will be resolved soon–or at least a viable workaround or configuration option.

Thanks!!!

6

Hi @kirkpabk,

Have you tried the solution provided in the first message, to add “spn:” in the Application ID ?
If yes, if will help us understand better what is happening for AAD users.

Thanks !

7

Thank you Julien for the reply. Yes, I have tried that. The AD FS server replies that the endpoint identifier does not exist, so we are passed that with the correct identifier. We do not have/use the spn: prefix in the name/endpoint identifier. The logs also only reflect the correctly configured identifier as expected.

I no longer believe that the Application ID is our issue. I have posted my update on another entry.

8

Ok, thanks for the clarification. I’ll have a look at your other post then.

9

Hello Brian,
I have the same issue than you on IIS.
Can you please explain how you fixed the issue ?
Thanks
Remi