What is the best way to provide access to projects and spaces?

[#1]

This article has been created in close collaboration with @Paula Kraszewska whom I cannot avoid mentioning here for her very valuable contribution. Thank you!

Hi Atlassian Community!

Along this article, we are going to share with you many aspects around the management of user access to Jira projects and Confluence spaces on a big Atlassian Cloud instance.

Introduction

As site administrators, we frequently find users requesting help because they want to grant access to multiple Jira projects and/or Confluence spaces, and that’s a time consuming task.

The task can get even worse when they want to restrict Edit Page permissions on multiple pages on a one per one basis!

Sometimes we are being directly suggested to use Atlassian User Groups in the hope that they can solve their access management needs, since only Site Admins can create groups or manage the users who belong to them.

Along this article we will elaborate on:

• Several aspects of Atlassian User Groups

• Our opinion on what constitutes an appropriate usage of groups in a big instance

• Implications of using groups for project/space access management

• What future improvements may come over time to improve project/space access management

• How to minimize the workload of providing access to Jira projects and Confluence spaces

We hope this article is useful for less experienced site administrators and also receive feedback from more experienced ones.

Thank you in advance for your feedback and enjoy reading!

What can Atlassian User Groups be used for?

Let's quickly summarize what user groups can typically be used for:

1. Provisioning a Jira and/or Confluence license.

2. Granting several global permissions in Jira and/or Confluence.

3. Granting access to Jira projects and Confluence spaces.

4. Referencing them in JQL filters.

Points 1 and 2 are use cases that will always exist, since there are no alternative ways of setting them. The usage of groups for these use cases is mandatory and the only technical option and we think they work perfectly for these purposes. Nothing to change here!

However, points 3 and 4 are use cases which purpose can be technically fulfilled by any users, just by covering the need in a different way.

Our opinion

We think that Site Administrators of big instances should only be responsible for managing groups for purposes of points 1 and 2:

1. Provisioning a Jira and/or Confluence license.

2. Granting several global permissions in Jira and/or Confluence.

We are going to argue this opinion below.

Why we think it is better not to use groups for managing access to specific projects and spaces?

There are multiple reasons why we think it may be suboptimal to use groups for granting access to Jira projects or Confluence spaces, and we are going to elaborate on that.

Users other than Site Admins can grant access to projects/spaces by themselves

The first and most evident reason for Site Admins not to assume the task of adding users to projects or spaces is simple: Users can manage project and space access by themselves by adding individual users to them.

Users can be provided with Project Administrator permission so that they are able to grant access to Jira projects.

Similarly, users with Admin permission in a Confluence Space can grant other users access to that space.

Removal of bottlenecks: Avoiding the dependency on Site Admins

Since users can have the ability to manage project and space access on their own, there is no need for creating a dependency on Site Admins availability, which would be a clear bottleneck.

If Site Admins were unavailable, project and space access would be blocked!

We can only remove this dependency by making users responsible for managing access to their own projects and spaces.

In our opinion, it wouldn’t be acceptable that new joiners had to wait for days or weeks to start working on Jira or Confluence just because any circumstances made no Site Admins available.

Workload distribution

The ratio Users per Site Admin in a big instance is at least of several hundreds to one, if not thousands.

As a rule of thumb, a need that can be achieved by users should be delegated to them.

That’s because, by doing so, the workforce is multiplied by several hundreds of times.

Responsibilities

Since Site Admins are usually also Jira and Confluence administrators, they have a lot of workload related to different things that cannot/should not be delegated to users.

Those are the kind of tasks in which we think they should invest their time and also in which they can add the most value.

Transparency

Users are not able to see the list of users who belong to a group.

Unlike that, users can see the list of users that had been added to a project role or to space permissions.

The lack of transparency may cause serious issues with impact on budgets.

Since users lack the ability to see who belongs to a given group, they can’t detect if a given user still has access to their project and, therefore, they hardly ever request users to be offboarded, causing licenses that are no longer needed to be unproductively paid for several months.

As a side effect, the lack of transparency also ends up with users raising multiple duplicate requests of adding a user to a resource the user could already access, just in case, especially after detecting a different colleague could not access a given resource.

In our experience, using groups for project and space access management ends up being an extremely inefficient method.

While instances with both Jira and Confluence can insert the User List macro once per each group in one or multiple pages, this workaround is far from being a good enough solution, since groups with project access are checked on the People section of a Jira project while the list of users who belong to said groups need to be found in a specific Confluence page. This solution would only work for users who knew the list of group members needs to be checked in a given Confluence page, and even for those users, there would be ergonomy issues and extra effort to get to the information.

Principle of least privilege

It is generally accepted to be a good practice to grant access by the principle of least privilege.

We think using groups for provisioning access to multiple Jira projects and Confluence spaces is kind-of the opposite to having the required granularity to comply with that principle.

Some of the benefits of applying this principle include:

• Ease of finding content relevant to the user

• Overall improvement of application performance

• Better data protection

• In the issue navigator (where users build their filters), being suggested just the custom fields*, labels and statuses that exist in the projects the user is able to access. This reduces the risk of committing errors.
  *This only works if the custom field a) had its context narrowed, or b) had been hidden in the Field Configuration.

Centralized vs Distributed access management

The categorization of users in groups, if managed centrally, is a task that is better approached by setting Active Directory together with an app that synced with it, possibly Atlassian Access.

However, we are sceptic about using Active Directory groups to provide access to resources like Jira projects or Confluence spaces, since all of those components evolve independently and in an unrelated way.

There is a risk of ending up using so generic and unspecific groups that belonging to one of them would provide access to too many unrelated projects and spaces, and possibly to many other unrelated resources in many other apps.

While it could make sense to use AD groups just for app license management, there would be a risk of penalizing agility of processes way too much. At least in the case of Atlassian apps, it is possible to automatically accept access from user accounts belonging to whitelisted domains, among other options.

In the context of a big enterprise, we think it makes no sense to centrally categorize users over and over again on a per app basis.

That said, we reckon it is better to use a distributed (not-centralized) user management process on a per resource basis.

In that regard, besides the current possibility of individually adding users to Jira project roles and to Confluence space permissions, we think the future may bring the ability of adding user-managed teams for distributed user access management, as we will see in the section A look into the future.

Automatic early detection and offboarding of unnecessary user accounts

The process of offboarding users from Jira and Confluence may be extremely inefficient.

In our experience, the vast majority of inactive users are detected by manually downloading a CSV of users, detecting users who have not logged in during the last three months or so, copy+pasting each of those user accounts to Atlassian User Management and manually deactivating them on a one per one basis.

As a side note, it might be viable to develop a script for deactivating unused accounts, but so far we have found no REST API methods for returning the last time a user logged in to Jira or Confluence. Any ideas?

In our experience, we rarely deactivate inactive users as the result of a explicit request for offboarding the user. And even when we receive one of such requests, sometimes it ended up deactivating a user that needed to continue working on a different project.

We think explicit offboarding requests are so relatively infrequent because of users being unable to see the list of users who belong to a group, as previously mentioned in the Transparency section.

But the most important thing about all of this is: During the time that needs to elapse in order to be able to detect inactive accounts, licenses are being paid with no real need for doing so.

If users were individually added just to the projects and spaces they really need to access, that would open the possibility of fixing several important problems regarding inactive users:

1. There would be no need for explicitly requesting the removal of a user from a specific project/space. Any user with admin access could remove the user directly.

2. A programmatic solution could check for users not being present in any Jira project roles or Confluence Space Permissions and automatically remove their Jira/Confluence license. We think a solution like this wouldn't be effectively possible if that access were being granted through groups.

A look into the future

We think a not too far future will bring new things to make it easier to manage project and space access.

The new Atlassian Team feature

Atlassian has developed a relatively new feature for users to be able to manage Atlassian teams.

The potential to use teams in project roles and space permissions would revolutionize project and space access management, making it an easier and more user-friendly task.

Delegation of space access permissions to its linked Jira project

Some time ago, we published an idea about a new feature to better integrate permissions between a Jira project and its linked Confluence space.

This feature would reduce the administrative workload of dealing with project and space access.

This would be a minor improvement compared to the potential of adding the new Atlassian Teams to project roles, space permissions and page restrictions.

Conclusion

Although using groups for resource access management is possible, we think it is clearly outperformed by letting the end users manage access to their individual resources.

For the sake of brevity, we have created a new article with the section How to minimize the workload of providing access to Jira projects and Confluence spaces.

We would love to hear your feedback on this subject!

What are your thoughts? How are you dealing with access management? Are you maybe using a smart solution you want to share?

Thanks for reading and thank you in advance for your feedback!

[Ollie Guan]

TKS @Ignacio Pulgar 

[Ignacio Pulgar]

Thanks for supporting these ideas @Ollie Guan!

Also, thanks Appwide for sharing this article in LinkedIn stating it is a must-read (this is the best compliment an article could receive!) and for creating such a funny meme! It made me laugh out loud!

Let me share your invaluable post here:

https://www.linkedin.com/feed/update/urn:li:activity:6910513351722729472/

[Bryan Guffey]

Great article! Here's the question, however: How do you get the space or project admins to actually do the work of adding and removing users to their projects and spaces, instead of reaching out to you to do it anyway, because it's not part of their expected work? 

I think we have to answer this question in order to make your idea work; otherwise, I am very much interested in this model! It has a lot of potential!

[Ignacio Pulgar]

Thanks @Bryan Guffey !

I have some ideas that may work. I will create a new article with a detailed potential solution. I promise!

BR

[Tom Lister]

Great article @Ignacio Pulgar 

I have followed a policy of giving users admin access to projects and spaces for the same reasons. Some users are more interested than others but constant feedback of - did you know you can do this - works over time. We tried delegated group management apps without success. The users needed some knowledge of our group naming to use it - not their day job.

We have groups of projects that mandate consistent processes across many geographical regions. These need groups for global reporting and QA functions. But not for local access.

[Paula Kraszewska]

Thanks @Ignacio Pulgar, great article as always!

[Ignacio Pulgar]

Thank you @Paula Kraszewska! You've had something to do with that too.

Thanks @Tom Lister for sharing your nice words and experience!

[Tere Pile]

Agree w/this, when taking over for a past admin clean up was beyond painful.  Now it's up to the project admins, but I feel their pain in maintenance when they handle multiple projects.  Possible solution - enchancing the Team feature would be nice.  Allowing project access to a 'team' might be a vaiable solution if functionality was allowed.  Yes, that has it's own drawbacks and would require enhancements to teams but would put some control w/Project admin vs. site admin and eliminate having to assign multiple persons to a project/role.  Submitted awhile back spoke w/someone didn't go anywhere that I know of.  But I keep trying. 

[Federico Kiwam _Elite IT Consulting Group_]

Hi Ignacio,

Great Article, but unfortunatly in instance with so many user in some cases we had issues if more than 50 individual users are in a page for example in confluence we start to have some issues regarding for example to tags in the page.

For that reason in our case we were force to use group to avoid that kind of issues but as you said is really a big problem becuase many of the access depends on the Jira admins, but, we are studing to use an external self-made application to add user or take out using API.

Thanks again for the great information.

Regards,

Federico.

[Alan Kelly]

I have an instance of JIRA and Confluence running and I'm currently in trial for the "standard" license. I have created separate Spaces for different project within the company. These are coupled to identical JIRA projects to track related issues. We have internal team members split across projects ( less than 10 ). I can control which internal members see the projects in Confluence by adding them all to a "project group". However in JIRA the default permissions appear to allow every logged in JIRA user to see all projects. If I want to change this ( give certain members access to certain project )  do I need to delete each entry for "any logged in user" in the JIRA project permissions and replace it with a group permission? If so, is there a way to bulk remove the default ( there a loads of granular permissions ). thanks.

The idea presented here that groups are bad appears relevant when the company size is large and there are many more Atlassian tools in play. I'm the Site admin, space admin and I don't have any subbordinate project admins to delegate the work of " manage your own permissions". Also, we have external members assigned for license and I can't let them manage permissions ( It's them I want to segregate view from other sensitive projects ). Suggestions?

thansk

[Amaresh Ray – Multiplier]

Thank you for writing this @Ignacio Pulgar – this is a really important concept! 

@Bryan Guffey I agree that your question is key for this to be implemented successfully at scale.

Take a look at an article I shared on community a while ago on how Jira admins can delegate this to project admins and other users: https://community.atlassian.com/t5/Marketplace-Apps-Integrations/HOWTO-Automating-access-requests-for-Jira-projects/ba-p/2020611