Icon

This documentation relates to Application Links 4.0.x
If you are using an earlier version, please view the previous versions of the AppLinks documentation and select the relevant version.

Skip to end of metadata
Go to start of metadata

When you create an application link between two applications, the Application Links plugin automatically creates a link using OAuth security; this security method lets authenticated users take advantage of all the integration points between Atlassian applications.

 

On this page:

Depending on your permissions when you create an application (or the settings required in the application you are linking to), you might need to modify the authentication settings for an application link after it's been created. There are a few common scenarios in which you might need to change the configuration of an application link:

  • You've set up an application link but users still have to authenticate regularly. This can occur when the application link has been configured to not share the same userbase. If those applications do share the same user base, you can update your application link authentication by selecting the Allow user impersonation through 2-Legged OAuth check box on the incoming authentication settings for the application link configuration.
  • You want to continue using a link to an application that now allows public sign-on and the link was previously configured with a shared userbase. You can update your application link authentication by clearing the Allow user impersonation through 2-Legged OAuth check box on the incoming authentication settings for the application link configuration.
  • You use a plugin that requires a specific authentication type.

If you configure OAuth authentication for your application, please be aware of the following security implications:

  • Adding an OAuth consumer requires the transmission of sensitive data. To prevent 'man-in-the-middle' attacks, it is recommended that you use SSL for your applications while configuring OAuth authentication.
  • Do not link to an application using OAuth authentication, unless you trust all code in the application to behave itself at all times. OAuth consumers are a potential security risk to the applications that they are linked to because of the ability to impersonate users. If your server is compromised, the data there and on linked servers is at risk.
  • Note that creating a new application link now uses OAuth by default and enables both 3-legged OAuth (3LO) and 2-legged OAuth (2LO).
  • When updating older application links (that perhaps used Trusted Apps authentication) to use OAuth, 3LO is used by default, but you need to explicitly enable 2LO using the check box in the application link configuration settings.
  • Only use the 2LO with impersonation option in the application link configuration settings if your servers both have the same set of users and they fully trust each other.

If you configure Trusted Applications authentication for your application (your servers have the same set of users and they fully trust each other), please be aware of the following security implications:

  • Trusted applications are a potential security risk. When you configure Trusted Applications authentication, you are allowing one application to access another as any user. This allows all of the built-in security measures to be bypassed. Do not configure a trusted application unless you know that all code in the application you are trusting will behave itself at all times, and you are sure that the application will maintain the security of its private key.

Applications Links allows you to configure 'impersonating' and 'non-impersonating' authentication types:

  • Impersonating authentication types make requests on behalf of the user who is currently logged in. People will see only the information that they have permission to see. This includes OAuth and Trusted Applications authentication.
  • Non-impersonating authentication types always use a pre-configured user when making a request. Everyone logged into the system will see the same information. This includes basic HTTP authentication.

  • No labels

14 Comments

  1. I miss some information about two and three legged authentication.

    1. Hey Christian, what information are you after? - Christine

      1. Hello Christine, it would be interesting to now if it is possible to activate three legged authentication and how it is implemented (https://github.com/Mashape/mashape-oauth/blob/master/FLOWS.md#oauth-10a-three-legged in Atlassian Words and for Atlassian Products)

        1. Hi Christian,

          Application Links does support three legged OAuth. It can be configured when creating a new Application Link or an existing one can be reconfigured to use it.

          Regarding the implementation, could you expand on the kind of information you after?

          Thanks

          Mike

          1. Hello Mike,
            then please explain where it should be configurable. I have never seen that option or it is hidden by another name.
            Best Regards,
            Christian Schulz 

            1. Sorry for the confusion Christian.

              I've added the folowing to the page:

              • Note that creating a new application link now uses OAuth by default and enables both 3-legged OAuth (3LO) and 2-legged OAuth (2LO).
              • When updating older application links (that perhaps used Trusted Apps authentication) to use OAuth, 3LO is used by default, and you can explicitly enable 2LO using the check box in the application link configuration settings.

              I hope this is clearer.

              1. So it means there is no possiiblity to switch between 3LO or 2LO? It is always 3LO, when possible?

  2. Can You make a table, saying what type of information can be shared with specific type of application link?

    I`ve made applink with basic HTTP authentication between two Jiras and I can see that only activity stream works, there are no information shared on a project basis and I can`t make any project link. I`m not sure if this is as it should, or am I missing something.

  3. I switch both JIRA and Confluence from http to SSL.  Since then for the JIRA Macros on confluence I've gotten these errors below, please keep in mind JIRA Macros were working prior to switching to SSL:

    An error line ending with:  "java: unable to find valid certification path to requested target."

    a. I tried setting up JAVA_HOME variables,

    b. I have tried pointing java to the proper keystore for tomcat's certificates

    c. I tried setting proxy ports to 443 in server.xml

    d. I tried making changes to the Application Links settings.

    e. I tried upgrading JIRA macros and now the error message shows:

     "Unable to render JIRA issues macro, execution error."

    Are there any specific instructions for making JIRA Macros work with SSL on both JIRA and Confluence?

    Thanks in advance.

    1. Sorry to hear this is giving you trouble Marcelo. Please raise an Atlassian Support request at http://support.atlassian.com/ - that will be a much faster and more systematic process than we can achieve with comments on this page. 

  4. In JIRA, trying to access the Outgoing Trusted or OAuth config screen is not working.  The spinner just spins.

    1. Hi Chuck. Please raise an Atlassian Support request at http://support.atlassian.com/ and we can help you to resolve this.

      1. It is either a Chrome issue or and issue with JIRA on Chrome.  It would not work in Chrome.  When I tried it in Safari it worked great.  So I got the integration working.