Skip to end of metadata
Go to start of metadata

Atlassian applications work together to provide best of breed integrations to streamline your software development or other projects.

You get Jira Software and Confluence or any of the Atlassian developer tools working together by creating an application link between them. See how to do that below.

We recommend that you use OAuth authentication for application links, because of the greater security inherent with that protocol. We don't recommend using the Trusted Applications or Basic Access authentication types anymore. 

If you need to update an existing application link see OAuth security for application links.

If you want to connect Jira Software to Bitbucket Cloud see Use the Jira DVCS Connector.

 

Link from Jira applications

Create an application link from within Jira applications such as Jira Software.

  1. Go to the admin area in Jira Software and click Application links.
  2. Enter the URL for the remote application you want to link to and click Create new link.
  3. Complete the application link wizard. You must make use of the automatic link-back from the remote application to get full integration (you'll need system administrator global permission for that).

For more details see Using AppLinks to link to other applications in the Jira admin documentation.

 

Link from other Atlassian products

To create an application link from other Atlassian applications, just go to the admin area of one of them.

For specific instructions see:

 

Link Atlassian Cloud applications with server applications

You can link Atlassian Cloud applications, such as Jira Software Cloud or Bamboo Cloud, with server applications such as Bitbucket Server and Fisheye. 

There are some things to consider:

Impersonating and non-impersonating authentication types

Atlassian's application links provide both OAuth and OAuth with impersonation authentication types:

OAuth authentication

Non-impersonating authentication allows you to link applications when the applications don't share the same userbase.

It always uses 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 based on the access permissions of that pre-configured user, and this is used for requests from all users.

See OAuth security for application links for more information.

OAuth with impersonation

Impersonating authentication makes requests on behalf of the user who is currently logged in. People will see only the information that they have permission to see. This should only be used when two applications share the same userbase, typically managed with an external directory using LDAP.

Provides greater convenience for your users – they don't need to authenticate when they request restricted resources from the remote application. The following restrictions apply:

  • Both applications must be Atlassian applications.
  • Both applications should share the same userbase.

See OAuth security for application links for more information.

 

When you're not an admin on both applications

Where an admin of two applications creates a link between the two, the Application Links plugin will create both incoming and outgoing links between the applications and will also configure authentication on both links. This diagram illustrates this 2-way scenario:

 

However, if you are an admin on only one system, you can still create an application link, but the Application Links plugin will create an outgoing link only, and the link won't have any authentication configured:

 

In this scenario, the application where the link originates can access publicly-accessible data from the other application. For example, this type of link could allow a Confluence application to include a link to a Jira Software issue, but you wouldn't see restricted issue information in Confluence until you authenticate with Jira Software.

If you create an application link and aren't an admin on both applications, you can complete the link by signing into the other application with admin permissions (or having an administrator on that application sign in) and then create a link back to your application.

 

You may need to update an application link if the remote application has changed to a new address.

You may see a message if:

  • The remote application can't be reached: you should check your network configuration and ensure that your remote application is running.
  • The remote application has changed to a new address.

If the address has changed, you just need to click Relocate in the message, enter the new URL for the remote application of your application link, and click Relocate.

  1. Log into your application as an administrator.
  2. Go to Application Links in the left-hand panel.
  3. Choose Delete from the Actions menu for the link.

The application will attempt to contact the remote application to delete the link. You should delete both ends of the link before recreating it.

In some cases, it may not be possible to automatically delete the link from the remote application. You'll need to log in to the remote application as an administrator and verify that it has been deleted correctly.

  • No labels