HTTP Header Authentication
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
Configure your reverse proxy to inject a HTTP header containing the authenticated userid
Install the application from the Atlassian Marketplace:
Confluence: https://marketplace.atlassian.com/manage/apps/1221608
After Installation, open the configuration page in the User Management section:
Header Name
Set the Header Name to the header sent by the reverse proxyAllowed 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 authenticationInject 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.invalidip | Logs the authentication result if the authorisation header should be used but the request is not coming from an allowed IP address |
de.resolution.httpheaderauth.nonauthurl | Logs the authentication result if the requested URL does not require authentication |
de.resolution.httpheaderauth.nouser | Logs the authentication result if no authentication header value was present |
de.resolution.httpheaderauth.alreadyauthorized | Logs the authentication result if the user from the authentication header is already logged in |
de.resolution.httpheaderauth.fail | Logs the authentication result if the authentication fails (e.g. because the user is missing or does not have the required privileges) |
de.resolution.httpheaderauth.error | Logs the authentication result if an error happened in the authentication process |
de.resolution.httpheaderauth.success | Logs the authentication result if the authentication was successful |