Defining access and security

When it comes to access and security, every setup have its own requirements. There are some guidelines I think is important however and one of them is to make the Jira Admins less dependent on external management. By this I mean that you should consider moving as much as possible into roles when it comes to access management.

This way you will not only empower the Jira Admins so they can manage who can and can not do things in the Jira Project they are in charge of, you will also shift the responsibility of access to them as well.

One of the big issues I see in many Jira installations is that there are often a very long chain to gain access, especially in setups using any form of AD. While waiting periods to gain access is annoying, the big issue comes by the fact that since no one really is responsible for the access, you often have a lot of people that should not be there anymore.

The off boarding process rarely exist in these setups and that is not just a problem from a security and access perspective, it also clutter up the database with old projects, old fields and of course old users.

So what we do in Jira is that we define a permission scheme that is based on roles. I tend to define this in three levels, but you might need different levels depending on your setup.

1. Jira Admin (Role) - This role get full access to all functions.
2. Project Member (Role) - This role get full access except for:
   • Administer Projects
   • Delete all comments
   • Edit all comments
   • Delete all attachments
   • Delete all worklogs
3. Watcher (Application Access or Role) - Depending on your setup you either connect this to all logged-in users, or a project role. Watchers get permissions to view projects and to comment only.

The idea behind the watcher level is to allow people that may not have a direct role in the team to still be able to see and comment on things. This is useful for stakeholders and in some cases for product owners as well. The reason we do not give them Project Member access is that we want to avoid that people outside the team start to assign or create new things as that causes a big mess.

Normally I suggest connecting the watcher level to application access so it is automatic and it allows for free roam across project borders. Not everyone is comfortable with that however, or need a more closed down setup for various reasons. In those cases you instead connect this to a project role. This will allow the Jira Project Admin to manage the access manually for more control.

On top of this we add Site-Admins that of course get full access as well tied to their group. This is so they can do their jobs to administrate and help all users in Jira.