Running SonarQube behind an IIS Reversed Proxy

  • Article

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

  • Install the prerequisites software on IIS, including Application request Routing (ARR) and the URL Rewrite modules.
  • Verify that SonarQube is running and available on https://privates_sonar_host:sonar_port/ (typically https://localhost:9000).
  • You may want to refer to Jesse's blog Configure SSL for SonarQube on Windows for a step by step configurations.
  • *Important* Make sure to turn off the checkbox “Reverse rewrite host in response headers” within the ARR (Application Request Routing) configuration of IIS. (Application Request Routing Cache --> Server Proxy Settings)
    SNAGHTML23d0be3
  • Edit the web.config file for the configured website to include the following rewrite rules:

<?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="^https://[^/]+/(.*)" />
<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="https://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: