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 authentication; this authentication method lets logged-in 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.

Note that to get the full integration available in the Development panel in JIRA issues, JIRA must be connected with Stash, FishEye, Crucible or Bamboo using a 2-way application link that has both 2-legged (2LO) and 3-legged (3LO) authentication enabled. See Installing Atlassian Tools for Integration with JIRA for version information and connection details.

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.

Application links allow 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, and should only be used when two servers share the same user base.
  • Non-impersonating authentication types always use a pre-configured user, and not the logged-in user, when making a request. The server handling the request determines the level of access to use, and this is used for requests from all users. This includes basic HTTP authentication.

  • No labels

19 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.

        1. Yes, most definitely a manifestation of the over-caching that Chrome does in iframe UIs like that which is used in the Application Links admin. We were pulling our hair out over this, but solved the crosstalk by splitting JIRA and Stash instances and base URLs between two new unique host names. They were originally referred to by the same name. For now, we have only 2-legged OAuth configured between the two, and nothing else. All is right with the world....

  5. Clearly this documents needs a serious rework, there are 3 types so there are at least 7 ways to configure the app links.

    We need a table with examples regarding when to configure one way or another.

  6. I can't find the location in JIRA to configure this.

    Can someone please show where this is located?

    Thanks!

  7. The "Application Link" is actually in Fisheye, the documentation needs some work!