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 126.96.36.199506
- 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)
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,