Hi Dominik,
Sorry, but I really don’t know where to go with this from here.
Ann
Well, I can offer you a MS Teams call if it helps to pin down the issue. I live in CEST time zone, I guess you do are in the US somewhere? I guess we can figure out a date & time 
Btw. we are about to buy a license of SonarQube - Can we then “officially” open a support ticket with this SAML2 issue or how is this been done?
Hi,
If you’re buying a license that includes support (not all do) then sure!
HTH,
Ann
Thanks for pointing that out, I didn’t realize that there is no supoort in paid versions, if its below 20Mio LoC or additional 20k.
Anyways, we finaly have our paid instance of SonarQube up and running on a new server and having the very same issue.
I also checked out: SonarQube Users: Let's talk about IIS and SAML Authentication! and configured IIS as described in Operating the Server | SonarQube Docs that links to Configure SSL for SonarQube on Windows
Maybe @Colin might have an idea?
Hi @DominikTouring ,
Sorry for the delay. We are not managing to reproduce your issue, and we don’t even see how it would be possible by looking at the code.
Do you still have the problem? If so, could you double-check the value of sonar.auth.saml.loginUrl? Where did you configure this, via the conf/sonar.properties file, or via the admin UI (or both)? If via the conf/sonar.properties file, could you double-check you don’t have 2 entries, once being incorrect?
Hi,
I now even added the sonar.auth.saml.loginUrl with our IdP address also to conf/sonar.properties and restartet SonarQube - Same effect as before and not working.
As we bought the developer edition of SonarQube and created a fressh new server, we did the set up as described in your official documents, it should be easy to reproduce.
You mean, on our side? Because that’s the thing: so far, we don’t manage to reproduce it 
. And looking at the code, we don’t understand how this is even possible:
- There’s no way for the code to confuse/mixup these 2 settings when doing the SAML dance (
sonar.auth.saml.loginUrlandsonar.core.serverBaseURL). - Worse, there’s no processing done on
sonar.core.serverBaseURL: it’s read and used as-is, as defined by the user. We don’t use any mask or string replacement, so we don’t see how the URL in theLocationheader can be partially correct.
I’m out of my depth here, and I don’t see how I can help you further.
Hi all,
we have exactly the same setup in our company and have been looking for a solution to the same problem for a long time.
The answers in this post gave us an idea which was finally the solution.
To run Sonarqube on a Windows server behind an IIS a HTTP proxy or HTTP redirect is needed. For this, both inbound and outbound rules are defined.
Unfortunately, the SAML redirect is changed by the outbound rule during the SAML login, so an exception must be created in the outbound rules.
In our example we use Azure AD as login provider.
- navigate to your IIS page in the “URL Rewrite” section
- double click on the outbound rule
- open the Conditions tab
- create a condition with the values:
“Condition input” = SAML Login Url (e.g. “https://login.microsoftonline.com//saml2”)
“Check if input string” = Does Not Match the Pattern
"Pattern = SAML Login Url (e.g. “https://login.microsoftonline.com//saml2”)
“Igore case” = checked - apply changes in the upper right corner with “Apply”
The SAML login should now work correctly.
2 Likes
!Hi!
We configured everything to the SonarSource documentation, which links to
There are no outbound rule defined, so we do not have one, we only have one inbound rule, so why should there be a change of the URL in the first place?
Did you configure IIS in another way than described in the official documentation? If so, how does your outbound rule look like (the screenshot of the condition only, doesn’t help)
Thank you!
1 Like
We have finally a workarround for those, facing the same issue:
We basically created another Rule, that checks if the URL contains /adfs/ls (eventhough it would be wrong address, as it still readirects to itself https://sonar.oe.intranet/sessions/init/saml?return_to=%2Fprojects))
As a pattern wie look for
^adfs/ls(.*)
and than we use a “Redirect” as Action type:
https://myidp.com/adfs/ls{R:1}
This rule needs to be on the top:
So every time SonarQube is doing a wrong redirect to itself but with the correct path, we simply replace the wrong sonarqube host address with the correct adfs one and everything works as it should.
2 Likes
Hi,
Got the same issue after trying to setup SAML on my instance, you don’t need to add an outbound rule to rewrite it, you need to :
- Disable “Reverse rewrite host in response headers” in your Application Request Routing Cache :
- IIS → Your server → Application Request Routing Cache → Server Proxy Settings (Action pane) → Deselect Reverse rewrite host in response headers
- Add preserveHostHeader to your applicationhost.config :
- CMD as admin :
%WINDIR%\System32\inetsrv\appcmd.exe set config -section:system.webServer/proxy /preserveHostHeader:"True" /commit:apphost
- CMD as admin :
Source : iis - .NET Issue on ADFS SSO behind a Reverse Proxy - Server Fault
3 Likes
Working fine for us. Your solution is a little bit cleaner because you don´t modify the request via the rewrite rules. Thanks for that.
@ganncamp The solution of @Seddusff was the last missing piece to get it working properly.
You should definelty add this to your offical documention about IIS Reverse Proxy:
If you look at Using IIS on Windows on that page, there is an informative sidebar with a link to a guide from @Colin on that subject (I didn’t saw it too before getting the solution).
Edit : Didn’t saw you’d already checked it when looking for a solution
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.