Trusted Applications authentication Troubleshooting Guide
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
This document is a part of our Application Links Troubleshooting.
Solution
Atlassian recommends OAuth
All new Application Links are created using OAuth. It provides all of the functionality of Trusted Applications and Basic Authentication. OAuth allows applications to authenticate and authorise users without accessing their credentials.
Further Reading
What is Trusted Applications authentication?
Trusted Applications authentication allows one Atlassian application access to specified functions and data in another Atlassian application on behalf of any user. The user only needs to log in to one application, without needing to log in to the other. For this authentication to succeed, however, the user must have an account on both applications with the same user name.
For more information about authentication types, please see Configuring authentication for an application link.
Problems caused by incorrect IP address filters
Error Message | Description | Resolution |
|---|---|---|
BAD_REMOTE_IP BAD_XFORWARD_IP InvalidRemoteAddressException Request not allowed from IP Address | The IP Address is not listed in the "IP Patterns" of the "Incoming Authentication" screen. This message can also appear when using a proxy server; if the proxy server has a different IP address to the connecting application. In Data Center Products, each node of the cluster must be added to the "IP Patterns" section. This error will show up in the logs of the requesting application. | Ensure the IP address for each machine and proxy server is added to the "IP Patterns" section. If the IP Address for systems have changed, consider using static addresses or DHCP reservations in your network. You can make use of wild cards and comma separated lists of addresses: 192.168.*.* 192.168.1.1, 192.168.1.2 You can also make use of IPv6 addresses: 0:0:0:0:0:0:0:1 ::1 |
Problems caused by incorrect URL filters
Error Message | Description | Resolution |
|---|---|---|
Request not allowed to access URL | The URL that was requested by one application did not match an entry in the "URL Patterns" section of the "Incoming Authentication" screen. This error will show up in the logs of the destination application. | Ensure that the URL listed in the error is added to the "URL Patterns" section. You can make use of wild cards: /foo/* /baz/bar/ |
Problems caused by date and time differences between servers
Error Message | Description | Resolution |
|---|---|---|
CertificateTooOldException Certificate too old | The source application requested a certificate from the destination application. By the time the certificate arrived, the timestamp was older than permitted. In most cases this is caused by the time being substantially different between the two systems. This problem can be caused by network latency, causing the operation to take longer than the timeout. In rare cases, this error message may appear due to a combination of both cases. This error will show up in the logs of the source application. | Ensure the date and time are correct on both systems, and that the system time zone is correctly specified. In cases of latency, you may wish to increase the "Certificate Timeout" for both incoming and outgoing authentication. The default is 10 seconds. Setting the timeout value to zero (0) will disable the timeout, causing any delay or time difference to be ignored. |
Problems cause by inconsistent URL settings
Error Message | Description | Resolution |
|---|---|---|
BAD_SIGNATURE Failed to login trusted application <x> due to bad URL signature | The Application URL of the link does not match the URL that the remote application is reporting. This can be caused by: The Base URL on the remote application is set to something other than the Application URL defined on the link A reverse proxy or port forwarding is configured, and the "Host" header is reporting the wrong hostname and/or port. If this is the case, usually when using the affected application, it will have other problems besides application links not working. | If the Base URL is incorrect on the other application, change it to be correct. If the Application URL of the link does not match the Base URL of the other application, delete and recreate the link, which will pick up the current Base URL and set the Application URL correctly. If using a reverse proxy or port forwarding, ensure that "proxyHost", "proxyPort" and "scheme" are set correctly on the Connector element in server.xml, then restart the applications. Consult our Reverse Proxy and Application Link Troubleshooting Guide for more information. |
Emulating Trusted Applications authentication with OAuth
Using Trusted Applications is not recommended. You can accomplish an identical configuration by using OAuth, and selecting "2-Legged OAuth with Impersonation (2LOi)"
Was this helpful?