This app enables you to login a user based on a HTTP header.


Deployment Scenario

In a typical deployment, the Atlassian application is located behind a reverse proxy. This reverse proxy authenticates requests and adds a HTTP header containing the authenticated userid.

If a URL requires authentication in the Atlassian application, the userid from the header value is used to login in the user without any interaction.

The header value is just trusted without further checks. To ensure that no unauthorised access is enabled, make sure that

  • The header value is used only from requests coming from authorised IP addresses (usually the reverse proxy). This is done by adding only the reverse proxy's IP address to the allowed IP addresses below.
  • The reverse proxy is configured to always overwrite the header value used for authentication. Passing this value through from the client is a massive security issue and must be avoided!

Configuration

  • Header Name
    Set the Header Name to the header sent by the reverse proxy

  • Allowed IP Address Ranges
    Add the IP address ranges used by the reverse proxy. Requests coming from other IP addresses are just passed through without injecting authentication

    This list is empty by default. HTTP Header authentication will not work unless at least one address is added here.

  • Inject Authentication URLs
    By default, authentication is only injected if authentication is required for the URL, i.e. if your Atlassian product requires the user to log in before displaying the page. If you want to add authentication to other pages which do not require to be logged in, you can define those urls in here.

    Example: To inject authentication for the Jira Dashboard, add /secure/Dashboard.jspa to this list.

  • Search remote directories
    When this option is enabled, remote directories (LDAP, Crowd) are queried to find or update the user during login. This is enabled by default.

  • Trigger update in Crowd
    When this option is enabled, a HTTP request is sent to Crowd servers during authentication. This requires a Plugin to be installed on the Crowd Server, see Crowd with remote directories for details (this article is about SAML SingleSignOn, but applies here also).

Troubleshooting and Support

If you have any questions or problems, please contact our support via https://www.resolution.de/go/support. You can also book a free screen share session via https://www.resolution.de/go/calendly.

For debugging and troubleshooting, you can enable specific DEBUG logging. All these loggers have the base de.resolution.httpheaderauth

It's possible to enable DEBUG logging for de.resolution.httpheaderauth, but it's strongly recommended not to do this on a busy system as it will produce log lines for every request entering the system 

de.resolution.httpheaderauth.invalidipLogs the authentication result if the authorisation header should be used but the request is not coming from an allowed IP address
de.resolution.httpheaderauth.nonauthurlLogs the authentication result if the requested URL does not require authentication
de.resolution.httpheaderauth.nouserLogs the authentication result if no authentication header value was present
de.resolution.httpheaderauth.alreadyauthorizedLogs the authentication result if the user from the authentication header is already logged in
de.resolution.httpheaderauth.failLogs the authentication result if the authentication fails (e.g. because the user is missing or does not have the required privileges)
de.resolution.httpheaderauth.errorLogs the authentication result if an error happened in the authentication process
de.resolution.httpheaderauth.successLogs the authentication result if the authentication was successful