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

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

[Yordanka Terziyska]

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. 

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

[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]

Thank you @Mykenna Cepek and @Christian Gaiser for the feedback! I really appreciate it! I have tested Backbone Issue Sync in Jira Cloud instances (have made just some basic tests to sync projects between two jira cloud instances) and yes, it is an option I am considering if we decide to go this way. Good to know who I can reach out to if this alternative becomes relevant. Thank you! 🙏

[Mykenna Cepek]

It's good to hear, @Matthias Gaiser _K15t_, that your sync app is continuing to pay attention to the Jira Server and Data Center markets.

My information came from both our own internal testing, and also from a large client who did their own substantial testing of several sync solutions, and ended up unsatisfied, creating instead their own solution using scripts and APIs.

I would still recommend Proof-of-Concept efforts to anyone, to ensure that a solution addresses all of your requirements and needs.

[Matthias Gaiser _K15t_]

I totally agree doing your own proof-of-concept is key in order to get a solution that fits your needs.

If there's anything missing when you do a POC and our solution doesn't match your needs, you can always get in contact with us. I can't promise we'll add your feature, but I can promise that we're listening.

[francis]

(Francis here - with the Exalate team - another issue sync app)

FYI
We are continuing supporting our apps way beyond the EOL of the underlying application.. For instance - our apps are still supporting Jira 6.3.  Although that Atlassian stopped to support this version long time ago, there are still customers actively using this environment.


Regarding the use case - there are a couple of our customers that have one central Jira (on cloud - used by the customer team).  For each of their partners (customers/suppliers) they did setup a Jira cloud instance - dedicated to one partner.

That way they avoid that information leaks between the customers themselves.
It is a more cumbersome setup - but it addresses a major concern.

More information can be found here

[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?

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

[Ken Siskind]

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]

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.  

[Yordanka Terziyska]

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:

1. Limited each customer to 10 guests (policed so inactive customers are disabled after 3 months of no activity)
2. created a group for each customer
3. created a project role that the customer group gets associated to
4. made all permission schemes project role based
5. made one generic set of schemes for issue type, workflow, screens, fields, permissions, isssue security and notifications that all customer projects use
6. made a blank template project that uses the same schemes to make pushing out issue layout changes easier to do
7. 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
8. made all filter and dashboard permissions project based so customers can only see whats been shared with their project
9. created a custom confluence space for each customer project linked it to the JIra project
10. 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.

[Yordanka Terziyska]

Thank you very much @Alex Adland for sharing! Very useful! Really appreciated! 

[Ken Siskind]

To answer your questions:

1) For external users, we just manually invite them through Jira.  Internal users are handled through Atlassian access

2) External users can only see a project when they are added to a role on an individual project.  If they don't have the role on a project, then they have no access to that project

3) they can see a list of dashboards, but since they don't have browse access to projects they can't drill into any of them.  You got me nervous about this one, so I just re-validated that this was the case. 

[Mykenna Cepek]

We also found a few other points of exposure, despite this type of "external user lockdown" via Jira Permission Scheme:

• Shared/public filters are visible. The content of those filters isn't accessible if the underlying project isn't accessible by the external user. But the names of the filters are exposed.
• Similar to the above for Plans.
• Creation of new project Boards is still allowed.
• Changing the "Epic panel" setting under Board configuration is still allowed.