Controlling user access to JIRA Projects

[Charlie Cronin]

Hello there

I am running a Server based version of JIRA and need to be able to control/limit access to Projects on a per Project basis. To that end I’ve implemented the scheme identified by Robert Bradshaw (https://community.atlassian.com/t5/Jira-questions/How-can-I-restrict-a-user-so-he-can-see-one-project-only/qaq-p/264391) and whilst this works it is somewhat involved – adding group access for the variety of permissions ie Issues Permissions/Comments Permissions/Time Tracking Permissions etc is a bit cumbersome.

So I was wondering if I could create a template permissions scheme (eg ‘template-permission-scheme’) that have most permissions granted to ‘any logged in user’ with the except of ‘Browse Projects’ that only the administrator has access.

When I create a new project (eg project_xyz) I create and add users to a new project group (eg restricted-to-project-xyz-group), copy the ‘template-permission-scheme’, editing this new project specific permission scheme to only allow users who are in the ‘restricted-to-project-xyz-group’ to Browse Projects?

I have tested this and it appears to work fine. Users in the ‘restricted-to-project-xyz-group’ see the project/issues but any other user can’t. They can’t see the project-xyz in the list and direct links to a project-xyz board fail so all good.

This appears to be much simpler/quicker to implement than the scheme identified by Robert Bradshaw but I’m wondering if I have missed something? 

Does anyone have any thoughts / concerns as to why I shouldn’t implement my JIRA project access control like this?

Thanks for your time.

Charlie

[Joe Pitt · Accepted solution]

I think allowing 'any logged in user' will come around to bite you if you want any finer control. If you use project roles you will only need one permission scheme and allow much finer control of access. 

JIRA works by GRANTING access. You can't restrict access. By default, it grants access to the group used to logon (see Global permissions to see the "can use" groups and admin groups).  This is where users are getting their access.

1. The FIRST thing you need to do to get control is to remove any groups with logon privileges from the permission scheme unless you absolutely want everyone to have that permission.
2. Then I suggest you setup Project Roles for the various functions like, tester, QA, Browse Only, etc.
3. By using project roles, one permission scheme will cover all projects. The project admin controls project role membership
4. If the project leads want everyone that can logon access to the project they can add the logon group to a project role with the desired permissions.

This may be a big effort, but it will pay off down the road by making it easy to control access.

Most of the 'old timers' use project roles. It meets the best practice for security and gives complete control to the project lead for access to their project. JIRA comes with many project roles, but you can add more if you have a special need.

[Charlie Cronin]

Thanks for your response Joseph.

I take your points (#1 & #2) about ‘any logged in user’ being too wide a control and that certain permissions (etc ‘Manage Sprints’ and ‘Delete Issues’ etc) should be more controlled (by a Project Lead or similar). I’ve implemented a flavour of this in my template permission scheme.

I’m still not convinced that I can get away with (#3) - a single permission scheme for all projects. Typically with our other IT tools (Workspace/Sharepoint, Requirements Management tools etc) only users who need access to a specific project are granted permission. We’d want to replicate this control in JIRA.

As an example we have a System Design Authority (SDA) role (who will approve certain JIRA issues). We have a number of SDA’s within our business so multiple JIRA users will be assigned to this role. However for ‘project XYZ’ a single SDA user will be allocated to the project and due to the potentially sensitive nature of the project he is the only SDA who should have visibility of ‘project XYZ’.

To that end is limiting ‘Browse Projects’ to a specific group (and implementing your points #1 and #2 ) an acceptable way to control project access?

Thanks again for your time.

[Joe Pitt]

I've been using one permission scheme for years. The beauty of project roles is you can create any you need but a project admin doesn't have to assign anyone to them. You can assign groups to them or individual users (which is what I suggest for better project control). In your example of the SDA project XYZ will only have one user assigned to the role but project ABC can have five users assigned to it. You can also set conditions on transitions that only a particular project role can transition the issue. 

The problem I have with groups is the JIRA admin has to move users in/out the groups. If they are used in a project role the project now has a new user they may not want to have access. To have better control the number of groups can become huge if you have many projects.  Using roles give the project admin complete control over access to their project and transition issues. 

[Charlie Cronin]

Ah – lightbulb moment for me. I misunderstood the function / implementation of roles. I was thinking of each role as a silo of users (almost like a group) and that if you were in the ‘SDA role’ you had SDA permissions across all projects.

I now see how you only really need one permission scheme coupled with a set of roles.

Cheers for your help with this.

[Joe Pitt]

Great. If it works for you please mark the answer as accepted.