nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Managing Jira and Confluence Access for 'External Users'

Warde Wynter

It would be great to get peoples thoughts on the best way to easily and quickly manage (administrate) access to Jira and Confluence for external users

some context...

We have a number of 'external partners' that we collaborate with 'to varying degrees'

We want to be able to shared Jira 'issues' and Confluence 'pages' without having to move or copy them to dedicated (siloed) Jira Projects or Confluence Spaces

We simply want to be able to allow an External Partner User or Group access to specified Issues or Pages within a Project or Space, but limit access to that particular Issue or Page and their Child Issues / Pages

Currently we have to set up dedicated Projects and Spaces where we either move or copy Issues and Pages (and hence duplicate content)

I understand that Jira and Confluence are 'inclusive' products, but given the move towards collaborating and delivering across companies and organisations, it would be good to enable this without duplicating content

Any thoughts

Cheers
Warde

Comments

Mykenna Cepek

Atlassian recently rolled out an Early Access Program for their External Collaboration for Confluence. It is not yet available outside this EAP. But it may help to know that they are working on the Confluence side of this currently:

https://community.atlassian.com/t5/Confluence-articles/Introducing-External-Collaboration-for-Confluence/ba-p/1731502

As for Jira, I've found the problem to be more tractable. By using an appropriate Permission Scheme, and being very diligent, one can allow some level of "external access".

We are doing this now, and have one "external user" who has access to a single project with limited read-only access. Our use case that we're a consulting organization serving many clients. This external user has a PM-type role (for this one client) and this access provides visibility into our internal Jira, scoped to a single project which tracks the work we are doing for that client.

What we have learned is that you have to be extremely diligent in setting this up in Jira, and that maintaining it is constant and ongoing. If you have multiple admins, and they are not constantly on the same page, it simply might not be possible to maintain it. One wrong configuration might expose information you didn't intend, and likely you won't notice until much later.

Perhaps when Atlassian completes their External Collaboration for Confluence, they can work some similar magic for Jira. But the permissions structure between the two is quite different. I believe Atlassian is trying to create more parity between things like user Groups between the products. But we can be sure all of this will take time.

Kathi Paquet

You can also look at setting up a Security Issue Scheme. This worked for us on our HR Project we had.

AA_PH

How does this work/look like?

Yordanka Terziyska_cv6ezc

Thank you, Maykenna!

What is your experience of addressing this question with setting up a separate Jira environment that is designed to be shared with external users? That to mitigate the risk of exposing internal company information.

Cindy Sobus

We created custom groups, in user administration, then added those groups to projecs assinged to role of Users. All our internal users are also in a group, so each project will have at least our internal users group, and if accessed by an external group that will also be assigned with the same role of Users. We are not allowing external users access to Confluence, but this is working for us for Jira.

Mykenna Cepek

Separate Jira instances would have to share their data. There are (paid) Jira Apps which can sync between instances. You could spin up some free Jira Cloud instances and most Jira Apps are free for 2-4 weeks. Lots of opportunity to do Proof of Concept work, if you want to explore that direction.

I haven't used those sync apps (yet - there has been some discussion here). I have heard that non-Cloud Jira instances probably shouldn't sign onto a sync App, as the vendors aren't supporting them (due to the pending sunsetting of some of those non-Cloud platforms).

Jira permission schemes are quite capable of "mitigating the risk of exposing internal company information", as I noted above. The key risk is the human(s) in the loop. To mitigate that, keep the themselves in sync with the admin details on this critical issue. It sounds like that's important to the business, so make it a priority.

Ken Siskind_t6mj27

I did something similar.

1) I created an 'external' contractor group. Users added to that group don't get any of the usual default product access permissions.

2) For projects that have contractors, a project admin just adds them to the "contractor" role.

3) I created a specific permission scheme for the projects that I know will have contractors. I gave the contractor role the minimal permissions needed.

This works for us.

Ken Siskind_t6mj27

Before doing the above, I had a separate Jira instance for contractors and that was a big pain because we kept having to duplicate tickets.

Matthias Gaiser _K15t_

Hi @Yordanka Terziyska

I'm Matthias and I'm part of the team behind Backbone Issue Sync, such an issue sync app, @Mykenna Cepek mentioned.

We have several customers using our app to have an internal Server/Data Center instance which is not accessible from the outside world and synchronize parts of it with an externally available instance. This external available instance may be either Server/Data Center or Cloud.

I can definitely say that we are still supporting Server & Data Center customers to synchronize with other Jira instances - no matter what the deployment type is. And I'm pretty sure that this is also true for the other issue sync apps.

If you want to have a more detailed perspective on such a scenario, you can also check out this blog post on our homepage or contact us via help@k15t.com to discuss your specific use case.

Yordanka Terziyska_cv6ezc

Hi @Ken Siskind

Thank you for sharing! Really appreciated! May I bother you some questions around the concerns I have using this approach?

What solution do you use to manage the user base, i.e. are all external users added via the Jira application?
If you have f ex 2-3 externally shared projects, active at the same time, wouldn't then the users in the group 'external' group see all these projects? My concern is that I might end up with several 'external' user groups and difficult to manage in the long run in a reliable way.
What about filters and dashboards with sharing permissions that allow any logged in user to view? Any ideas how to make sure these are not exposed to external users. Or it might be just me missing something.

Thank you!

Alex Adland

We have about 140 Jira projects of which 100 are customer projects, which the relevant customers have access to so we did the following:

Limited each customer to 10 guests (policed so inactive customers are disabled after 3 months of no activity)
created a group for each customer
created a project role that the customer group gets associated to
made all permission schemes project role based
made one generic set of schemes for issue type, workflow, screens, fields, permissions, isssue security and notifications that all customer projects use
made a blank template project that uses the same schemes to make pushing out issue layout changes easier to do
came up with a layer 4 security level using conditioned workflow loops and transition screens so only our staff can edit certain fields on screens the customers have access to
made all filter and dashboard permissions project based so customers can only see whats been shared with their project
created a custom confluence space for each customer project linked it to the JIra project
set the security on the confluence space so the customers can only access their projects space, we do have to copy pages from spaces the customer cannot access in order for them to see those pages but we have a plugin to make that easy.

Mehr_miniOrange

Hi @Warde Wynter

This is a common challenge when trying to avoid duplicating issues or pages for external users. Since Jira and Confluence permissions are mostly managed at the project or space level, it’s not always easy to give very selective access without creating separate setups.

One approach that works well is to keep your internal structure as-is and share only specific issues or pages externally in a controlled way.

There are Marketplace apps that let you generate secure links for individual items, so external users can access only what’s shared without needing access to the full project or space.

This helps you avoid duplication while keeping permissions much simpler to manage.

Secure Share for Confluence is one such app that can solve this.

Hope this helps!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

access