JIRA/Confl Link - Limited Licenses or Other Potential Negatives?

Justin Cooke

Hi All,

I used many Atlassian products for years at my previous job (JIRA, Confl, Fisheye, Crucible, etc.), but only as a user and not an admin. At my new job, I'm now helping to administer JIRA and Confluence and will be setting up Stash soon. I'd first like to setup a JIRA and Confluence "Application Link", mostly so I can use the JIRA Issues Macro I'd gotten used to before, and I have a few questions.

- First, is the process of linking JIRA and Confl really as simple as it appears to be on this page?: https://confluence.atlassian.com/display/DOC/Linking+to+Another+Application

We're running JIRA 6.1.7 and Confluence 5.4.4 on the same internal server.

- Second, for whatever reason, we have a smaller number of JIRA licensed users than we do for Confluence (I was not part of that decision). Is that likely to cause trouble if we have Confluence users not licensed for JIRA viewing a page in Confl with the JIRA issues macro, for example? I think it'd be fine if the macro just didn't load the associated JIRA issues for those users, since they don't use JIRA anyway and wouldn't know about it.

- Third, are there any other potential negatives to linking the two apps that I should consider? I'm not seeing any, but I'd rather not suggest this app link to the primary JIRA/Confl admin and then find that I'm introducing some licensing or other problems.

The process appears to be simple and helpful. Any advice you can provide would be greatly appreciated.

Thanks!

Justin

minnsey

Hi Justin,

- First, is the process of linking JIRA and Confl really as simple as it appears to be...

Yes the process should be this simple, however there are a few things that can complicate the process and are worth checking before hand.

• It is simplest, but not mandatory, if each instance can reach the remote instance using the base URL of the remote instance, e.g.Configuring the Server Base URL
• The presence of proxies, firewalls, anything that might re-write urls or headers, between the 2 instances can effect the OAuth security scheme used to provide authentication on the link.

- Second, for whatever reason, we have a smaller number of JIRA licensed users than we do for Confluence (I was not part of that decision). Is that likely to cause trouble...

This is a common scenario and it shouldn't be an issue.

A default application link will use the Three Legged OAuth security scheme when making requests between the instance, this means each individual user has to authorize Confluence to communicate with JIRA on their behalf.

If a user does not have an account in JIRA then they can not give that authorization and therefore they cannot allow Confluence to access information in JIRA on their behalf. In practice this means, for example, that if a user is allowed to view a Confluence page that has a link to a JIRA issue, if they do not have permission to view that issue then the link will still be visible but no restricted details, e.g. the title, of the issue will be displayed.

If you do not share exactly the same set of users, refered to as the userbase, between the two instances, you do not want to check the 'shared userbase' checkbox during creation of the applink or manually configure Two Legged Oauth with Impersonation afterwards, see Configuring Authentication for an Application Link.

- Third, are there any other potential negatives to linking the two apps that I should consider?

No there shouldn't be.

I hope this helps move you forward.

Cheers

Mike