How to Configure Outbound HTTP and HTTPS Proxy for your Atlassian application
Platform Notice: Server and Data Center Only - This article only applies to Atlassian products on the server and data center platforms.
The content on this page relates to platforms which are not supported for JIRA Applications. Consequently, Atlassian cannot guarantee providing any support for it. Please be aware that this material is provided for your information only and using it is done so at your own risk.
This page defines how to configure Atlassian applications such that they can communicate externally through an outbound proxy. This configuration is required to access servers outside the network it's hosted in, such as the Atlassian Marketplace.
HTTP(S) Outbound Proxy support is configured in Atlassian applications by passing certain system properties to the Java Virtual Machine (JVM) on startup. These parameters are then used by the Atlassian application in order to send outbound requests via the proxy.
These basic properties follow the conventions defined by Oracle:
http.proxyHost property must be defined to configure an HTTP proxy, and
https.proxyHost for a HTTPS proxy.
http.proxyPort properties indicate the proxy server and the port that the HTTP protocol handler will use. For example:
-Dhttp.proxyHost=proxy.example.org -Dhttp.proxyPort=8080 -Dhttps.proxyHost=proxy.example.org -Dhttps.proxyPort=8080 -Dhttp.nonProxyHosts=localhost
http.nonProxyHosts indicates the hosts which should be connected to directly and not through the proxy server.
The value can be a list of hosts, each separated by a |, and in addition a wildcard character (*) can be used for matching. For example:
The pipe character (|) may need to be escaped in Linux, as per our JAVA Option '-Dhttp.nonProxyHosts' Does Not Work KB article.
System property configuration is described in further detail within our Setting Properties and Options on Startup documentation.
If your proxy requires authentication, you should configure it by passing the below properties to your JVM, as in our Setting Properties and Options on Startup documentation.
-Dhttp.proxyUser=atlaspirate -Dhttp.proxyPassword=yarrrrr -Dhttps.proxyUser=atlaspirate -Dhttps.proxyPassword=yarrrrr
Special consideration for Crowd:
For example, if you are using Bamboo with outbound proxy and you want to use Crowd as user repository then you have to take care of the below changes so that Bamboo can communicate with Crowd.
Edit the file: <bamboo-home-directory>/xml-data/configuration/crowd.properties and add the below configurations.
http.proxy.port=<http-proxy-port> https.proxy.port=<https-proxy-port> http.proxy.host=<http-proxy-host> https.proxy.host=<https-proxy-host>
The above example is given in a context of Bamboo with Crowd as user repository when using an Outbound proxy. But, these configurations can be referred to the other Atlassian application where we want to establish a connection to Crowd with the Outbound proxy.
Note: You need to restart your Bamboo application after making these changes.
Application Links Implications
http.nonProxyHosts property is not configured, all web requests will be routed through the proxy. This could break Application Links. For example, if connecting Confluence and JIRA applications together with Application Links, we would recommend bypassing the proxy and communicating on the internal network with this property. Routing through the proxy can have ramifications when taking into account IP validation on those links - the source IP of the server can be different depending on how the traffic is routed.
In a connection between JIRA and Confluence, for example, the
http.nonProxyHosts configured on the Confluence end must at least exclude localhost and JIRA baseurl, otherwise certain functionality may not properly work (JIRA tries to connect to itself and HTTP request can timeout or be blocked by proxy).
Similarly, you want to configure JIRA the other way around:
Microsoft ISA NTLM Authentication
NTLM is not supported by Atlassian applications. Please refer to public issues below, for example:
- - UPM-1104Getting issue details... STATUS
- - STASH-7694Getting issue details... STATUS
- - JRA-2398Getting issue details... STATUS
In past issues, customers reported success by using a software called Ctnlm. You can refer to the comments on our pages JRA-2398 - Support NTLM authentication and Problems Connecting to the Atlassian Marketplace.
The steps are summarised below:
- Install Cntlm Authentication Proxy locally your server where the Atlassian application is running
Configure and test it to make sure "Cntlm" works with your corporate NTLM and then use the parameters below
Update your user, domain, and proxy information in
cntlm.ini, then test your proxy with this command (run in your Cntlm installation folder):
cntlm -c cntlm.ini -I -M http://google.ro
It will ask for your password, and hopefully print your required authentication information, which must be saved in your
Username user Domain domain # provide actual value if autodetection fails # Workstation pc-name Proxy my_proxy_server.com:80 NoProxy 127.0.0.*, 192.168.* Listen 127.0.0.1:54321 Listen 192.168.1.42:8080 Gateway no SOCKS5Proxy 5000 # provide socks auth info if you want it # SOCKS5User socks-user:socks-password # printed authentication info from the previous step Auth NTLMv2 PassNTLMv2 98D6986BCFA9886E41698C1686B58A09
Note: on linux the config file is
- Have the configuration described on the HTTP proxy parameters point to the "Cntlm" proxy instead of the NTLM so "Cntlm" will do the job to talk to NTLM.