Running SonarQube behind an IIS Reversed Proxy


Securing your SonarQube server can be challenging. Previously there were many options to do so including: enable HTTPS on the embedded Tomcat server or reverse proxy. Starting with SonarQube 5.5, the support for running the embedded Tomcat Server over HTTPS has been dropped [Release Notes] and the only secured way is to set-up a reverse proxy like IIS, nginx or Apache in front of SonarQube.

If your SonarQube server is running on Windows, you may want to use IIS as a reversed proxy to secure the server access. This can be done by making use of Application Request Routing (ARR) and URL Rewrite modules. This is in particular the case if you need to enable the Azure Active Directory (AAD) Authentication Plug-in for SonarQube or any external login provider like (GitHub, Bitbucket, etc..). It requires the server to be exposed and secured using HTTPS for OAuth 2.0 provider to communicate with the external authorization endpoint (Azure AD, GitHub, etc...). In most of the documentations and blogs we've seen, this scenario is not addressed and break external providers, due to wrong URLs being requested.

In this post we will provide you with the guidance to configure URL rewriting on Internet Information Services (IIS) for to secure your SonarQube server over HTTPS. This will even work if your Azure Active Directory administrator requires two factor strong authentication (2FA). Although the guidance has been tested on multiple different environments, covering the login, logout, internal URLs and Azure AD login SonarQube scenarios, we recommend you validate it in your environment, before making changes to your production engineering environment.

The Azure Active Directory (AAD) Authentication Plug-in for SonarQube enables AAD users to automatically be sign up (a login is created if they don’t have one already) and authenticated on a SonarQube server. The latest version includes support for group synchronization from Azure AD to SonarQube.

image image image

Secured behind an IIS reversed Proxy

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <outboundRules>
                <rule name="ReverseProxyOutboundRule1" preCondition="IsRedirection">
                    <match filterByTags="A, Form, Img" serverVariable="RESPONSE_LOCATION"
                           pattern="^
http://[^/]+/(.*)" />
                    <action type="Rewrite" value="
https://public_sonar.com/{R:1}" />
                </rule>
                <preConditions>
                    <preCondition name="IsRedirection">
                        <add input="{RESPONSE_STATUS}" pattern="3\d\d" />
                    </preCondition>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                </preConditions>
            </outboundRules>
            <rules>
                <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="
http://privates_sonar_host:sonar_port/{R:1}" />
                    <serverVariables>
                        <set name="X_FORWARDED_PROTO" value="https" />
                        <set name="ORIGINAL_URL" value="{HTTP_HOST}" />
                    </serverVariables>
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

SonarQube 6.1, 6.2, ...

Updated: 2017.01.16 – Hosam Kamel

To support clustering capabilities in SonarQube, starting SonarQube 6.1 SonarSource team have rewrite the settings page along with web services.  You may check more details [MMF-339] Rewrite Settings WS and pages.

This change affects SonarQube installation exposed behind an IIS reversed proxy.

Why?

When using IIS as a reversed proxy, all requests coming to SonarQube pass through IIS first, then the rewrite rules dispatch the request to SonarQube installation. Because of the mentioned change, the URLs sent from setting pages to the SonarQube web services becomes very long and breaks the maximum query string limit for IIS, causes an error like below when you open the setting pages.

http-vs-https

When using Fiddler you will get HTTP 404 for the settings request, the query string length is 2202 character like below:

SNAGHTMLdbc73ca

 

fiddler

When tracing this using IIS Failed Request Tracing, it leads us to  HTTP 404.15 "Query String Too Long"

failedrequest log

Fix

To fix this, you will need to update the maximum query string property for the IIS website (the one used as reversed proxy for your SonarQube installation). By default it's 2048 Bytes, increase the maximum URL like below

max-query-string

Or simply edit the web.config we used above and add the new limit

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <security>
            <requestFiltering>
                <requestLimits maxQueryString="3000" />
            </requestFiltering>
        </security>
    </system.webServer>
</configuration>

Please refer to IIS Request Limits for more details.

We look forward to hearing from you

We need your feedback. Here are some ways to connect with us:

Comments (5)

  1. Peter Boevink says:

    Hi,

    I have additional info that might save other people a lot of time, since it cost me already quite some time to figure out why the configuration was not working in combination with the AAD plugin.
    It is very important to turn off the checkbox “Reverse rewrite host in response headers” within the ARR (Application Request Routing) configuration of your IIS webserver.
    If it is turned on, all outgoing redirects including the redirect to login.microsoftonline.com are rewritten to ‘https://public_sonar.com/’ which will end up with a status 404.

    Peter

    1. Hosam Kamel says:

      Thank you Peter, Indeed I was planning to update the post since we keep addressing similar issue on Github (https://github.com/SonarQubeCommunity/sonar-auth-aad/issues/4) … I have just updated the post to emphasize this point.

      Thanks again!
      Hosam

  2. Richard Schaefer says:

    I set this up and all I get is an HTTP 500 error. There’s a warning that I get in the ARR dialog that says “Server routing rules have not been created. Click the “Use URL Rewrite to inspect incoming requests” to create these rules.” There’s a Proxy Type section at the bottom of the dialog that has “Use URL Rewrite”, “Enable SSL Offloading” and a text box for “Reverse Proxy:”. Should this be configured? If not how do I best debug this?

    1. Hosam Kamel says:

      Hello Richard Schaefer,

      You need to install Application Request Routing module and enable it.

      To enable it, please Click:
      – Application Request Routing on IIS
      – Server Proxy Settings
      – Check “Enable proxy”
      – Select “Pass through” in HTTP version
      – Make sure ” Reverse rewrite host in response header” unchecked.
      – Then use the instruction on this blog post

      Regards,
      Hosam Kamel

      1. Richard Schaefer says:

        Thanks Hosam. I got those changes. I guess my web.config is wrong. What should “public_sonar.com” and “privates_sonar_host” be set to? IIS is running on the same server as Sonarqube so I set privates_sonar_host:sonar_port to localhost:9000. I’m fairly certain that’s right. Not sure about “public_sonar.com”? Is that the URL of the IIS Proxy site? (Tried that and it doesn’t seem to work)

Skip to main content