SAML configuration questions with Sonarqube 10.4, getting not valid audience for response error

Version: 10.4 build 87286. do not believe we’re using any plugins at this time beyond defaults

Deployed on ECS in AWS/docker

what are we trying to achieve: get SAML working

what have we tried so far: Most normal potions, a few seances, the usual profanity and late nights,etc.

TL;DR: Have configured SAML on the container (well, mostly, based on the error message), button shows up on the login page, goes to the IDP as expected, and after logging in there, pops up a

“Not authorized to access this page is not a valid audience for this response”

In digging around documentation and also leveraging the saml-tracer plugin I think I have the right stuff in the right places, the web logs do not show anything beyond the message displayed on the page, the entityID in the response matches the application ID in SQ, the cert in place, the username, login name and email are set and match the metadata from the provider.

I have tried both redirect and post methods (our IDP supports both, however I do not have direct access to how that is configured, I have to work with another team for changes to the SAML configuration… so I do not know what kind of stuff they have going on the back end), I will freely admit I am not proficient with Sonarqube nor SAML auth, although the latter does not on the surface appear to be all that complicated.

snippet from access log during one attempt(removed some basic http 200 entries) :



192.168.1.1 - - [03/Apr/2024:19:02:56 +0000] "GET / HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "76dff807-73a6-4d48-b6fe-5d0cc83fb376" 8

192.168.1.1 - - [03/Apr/2024:19:02:57 +0000] "GET /js/outWHCP76XN.css HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "d2be92d3-5667-4786-8deb-64199effe449" 3

192.168.1.2 - - [03/Apr/2024:19:02:57 +0000] "GET /api/users/current HTTP/1.1" 401 - "https:/sonarqube.test/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "2048e724-3c17-4134-a310-9450a54e2724" 3

192.168.1.2 - - [03/Apr/2024:19:02:57 +0000] "GET /api/l10n/index?locale=en-US HTTP/1.1" 200 - "https:/sonarqube.test/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "4bfc91f7-5c4a-40f0-a099-42d3864b538b" 28

192.168.1.1 - - [03/Apr/2024:19:02:57 +0000] "GET /api/navigation/global HTTP/1.1" 401 - "https:/sonarqube.test/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "5d257500-953a-4608-863e-50542f69e2c7" 2

192.168.1.1 - - [03/Apr/2024:19:02:57 +0000] "GET /api/features/list HTTP/1.1" 401 - "https:/sonarqube.test/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "30d2db55-e53b-4a34-abc6-11bba5925f1f" 3

192.168.1.2 - - [03/Apr/2024:19:02:57 +0000] "GET /js/outBIMYN2XL.js HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "9f2734e5-fcfc-48e1-93aa-25bdfb7c769e" 223

192.168.1.1 - - [03/Apr/2024:19:02:57 +0000] "GET /sessions/new?return_to=%2F HTTP/1.1" 200 - "https:/sonarqube.test/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "4546ecc7-ed7e-408d-9610-4054ec67f5c0" 5

192.168.1.1 - - [03/Apr/2024:19:02:58 +0000] "GET /api/l10n/index?locale=en-US HTTP/1.1" 200 - "https:/sonarqube.test/sessions/new?return_to=%2F" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "9352822a-0253-469b-8cf5-c3c79f88ed9f" 27

192.168.1.1 - - [03/Apr/2024:19:02:59 +0000] "GET /api/users/identity_providers HTTP/1.1" 200 - "https:/sonarqube.test/sessions/new?return_to=%2F" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "b43ae3a2-10d1-4abe-b09c-ca4e0c720f5a" 7

192.168.1.2 - - [03/Apr/2024:19:02:59 +0000] "GET /api/settings/login_message HTTP/1.1" 200 - "https:/sonarqube.test/sessions/new?return_to=%2F" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "011e065e-090a-4a39-8537-2bee50d7ea27" 3

192.168.1.2 - - [03/Apr/2024:19:02:59 +0000] "GET /images/sonar-logo-horizontal.png HTTP/1.1" 304 - "https:/sonarqube.test/sessions/new?return_to=%2F" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "72847f33-9ebb-4c29-b006-6b5d51f85cc8" 0

192.168.1.2 - - [03/Apr/2024:19:02:59 +0000] "GET /images/embed-doc/sq-icon.svg HTTP/1.1" 304 - "https:/sonarqube.test/sessions/new?return_to=%2F" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "7bde7a86-69f8-4089-94ee-c0f5cd073173" 0

192.168.1.2 - - [03/Apr/2024:19:02:59 +0000] "GET /images/saml.png HTTP/1.1" 304 - "https:/sonarqube.test/sessions/new?return_to=%2F" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "84d5174f-5e31-4e57-b908-80bd0415e684" 0

192.168.1.2 - - [03/Apr/2024:19:03:00 +0000] "GET /sessions/init/saml?return_to=%2F HTTP/1.1" 302 - "https:/sonarqube.test/sessions/new?return_to=%2F" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "f41ef4d1-8214-4b72-b56c-c8ee17f327e9" 10

192.168.1.2 - - [03/Apr/2024:19:03:01 +0000] "POST /oauth2/callback/saml HTTP/1.1" 302 - "https:/federation.test/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "5f12d161-1bdd-45c4-8b62-20ad8ecd8afc" 20

192.168.1.2 - - [03/Apr/2024:19:03:01 +0000] "GET /sessions/unauthorized HTTP/1.1" 200 - "https:/federation.test/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "42a73427-1cab-4e81-8a8f-1f06dee5c93f" 5

192.168.1.1 - - [03/Apr/2024:19:03:01 +0000] "GET /api/l10n/index?locale=en-US HTTP/1.1" 200 - "https:/sonarqube.test/sessions/unauthorized" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "6a4ee3d0-2417-4f1a-ae7f-0801370d835a" 28


Configuration: (the values have been adjusted slightly due to the nature of the environment it’s in)

-application id: https:/sonarqube.test

-provider name: sonarqube.test (is this critical? it states it is merely a display name)

-provider id: https:/federation.test/sso/saml_properties/1234

-saml login url: https:/federation.test/pool/sso/saml/authenticate

-identity provider certificate:

-saml user login attribute: common_name

-saml user name attribute: common_name

-saml user email attribute: sans (this was just added a few minutes ago, was previously blank and we’re not using email)

no group, and sign requests is not enabled.

What we got from our IDP folks is this:

-hostname (entityID/issuer): sonarqube.test

-audience : https:/sonarqube.test

-SSO endpoint /redirect url: https:/sonarqube.test/oauth2/callback/saml (this was pulled/derived from forum reading and could be the issue)

-saml subject name id: common_name

-saml metadata url: https:/federation.test/sso/saml_properties/1234/metadata.xml

in the metadata, the cert matches what’s configured in SQ, the assertions are there, the entityID is as entered in the SQ configuration.

In looking at the output from saml-tracer:

-audience value: https:/sonarqube.test

-issuer matches the provider ID

-destination matches the SSO endpoint

-Cert matches

-attributes match what’s expected

I’ve played with this a fair bit over the past couple of weeks (never all at once, which does hamper and slow the troubleshooting process) and have gotten things to this error page before I ran out of my admittedly low amount of talent. I have a feeling the issue is probably fairly minor, but I’ve kinda run out of ideas on this one.

The objective at this time is basically limited access to the SQ console to run analysis and create projects.

Also of possible value, the saml authenticated users (should) get the sonar-users group permissions, we’re not trying to do anything overly fancy with this at this time.

Thanks for assistance!

Hey there.

The error implies a mismatch between what is set for Application ID (SonarQube-side) and what is set in your SAML provider configuration (typically what’s called the the Audience URI or Entity ID ). These need to match.

Screenshot 2024-04-04 at 11.38.16

(you’re correct Provider Name is just a display name)

Based on the information you’ve provided, it seems they should match. However, you can check the logs to make sure.

If you bring the SonarQube log level up (global Administration > Log Level) you should be able to see the actual SAML request/responses in your web.log file. The audience looks like this:

<saml:AudienceRestriction>
<saml:Audience>https://sonarqube-test.com/</saml:Audience></saml:AudienceRestriction>

This is the value that needs to be matched. Is this verbatim the error message?

Something I want to double check: quote=“Kenneth Howard, post:1, topic:112629, username:Kenneth_Howard”]
“Not authorized to access this page is not a valid audience for this response”
[/quote]

Because usually the error message includes a value like:

“Not authorized to access this page <value> is not a valid audience for this response”

1 Like

Yes, that is the error message

You're not authorized to access this page. Please contact the administrator.

Reason:
https://sonarqube.test/ is not a valid audience for this Response

one thing that may be contributing to my confusion: I’ve defined most of this in the config file on the docker container, but have been making changes while testing from the console (not rebuilding in between, etc), and I see that in the error message there is a " / " on the end.
That slash is not in the text box in the saml configuration in the console, nor does it exist in the saml response from the IDP

Do the config file values override what’s entered in the console after deployment? (this is more a clarifying question because I’m going to review what’s in the deployment code, make changes there, and test it regardless lol)

1 Like

You need to define these values in the UI, and only in the UI.

Not a big fan of that from a future-management state (i.e. I have no desire to own the care and feeding of this or any of the tooling in our environment, so it needs to be as automated as possible with as few points as possible for pebkac’s -including my own- to creep in :smiley: )

At any rate, the config files do appear to override values put in the UI later on, after adjusting and adding a couple items, it now deploys and works as expected. I’ll make a note of this for our internal operational documentation :slight_smile: