JIRA integration with reverse proxy requiring authentication

Summary of Issue

The JIRA Manage Add-ons page (and several other features within JIRA) is attempting to communicate to itself and does so using the base address. In a network setup where there is a Reverse Proxy requiring authentication, the reverse proxy is forcing the internal traffic from JIRA to the SSO and does not permit the unauthenticated traffic to go through.

IN JRA-63795, we saw health checks failing because the requests from JIRA weren't permitted via the reverse-proxy based authentication. (In that scenario, however, the /rest endpoint was whitelisted, but it still produced an inconsistent result due to authentication at the reverse proxy level).

While we have the ability to bypass a reverse proxy/SSL by means of a secondary connector, we cannot tell JIRA to use this for internal requests - the Base URL is always used.

How to reproduce

The overview of the customer architecture is that JIRA webserver sits behind a client firewall which uses SiteMinder via an Apache Reverse proxy for authentication. JIRA appears to be using a plugin to read the logged in user from a cookie.

Expected Result

JIRA should be able to access itself locally and not go through the Reverse Proxy/external SSO.

Actual Result

JIRA is accessing itself via its base URL and the SSO is not letting traffic through that is not authenticated. 

Workaround

Workarounds will depend on your specific architecture, security requirements and other constraints. However, options include:

1. Whitelist requests from JIRA to itself to allow anonymous requests
2. If your authentication system supports it, use a plugin inside JIRA (rather than handling requests at the reverse proxy level) Moving the authentication to JIRA will allow it to correctly handle anonymous requests from itself.