Posted on Leave a comment

JIra Groups, Project Roles, and Permission Schemes Best Practices Survey

Rynder Roy Klomp

Toreno Information Solutions

WWW.TorenoIS.com

August 14, 2018

Jira Core: Groups, Roles, and Permission Schemes Survey

Objective of Survey

Determine if there is either: a) a consistent approach, or b) best practices with regards to the creation and management of Jira Core Groups, Roles, and Permission Schemes.

Context

While gathering information for my latest book, and talking with many Jira Admins, I found there appeared to be an inconsistent approach to managing Groups, Project Roles, and Permissions Schemes in Jira Core. Consequently, I decided to send out a short survey in order to determine if there is indeed a) a consistent approach or b) best practices with regards this topic.

 

Survey Approach

A Survey of 11 questions was produced, relating to the use of Jira Core Groups, Roles, and Permission Schemes. One of the 11 questions also related to the use of Active Directory (AD) and LDAP with Jira.

In addition to two System Administration experts (Philipp Sendek of brainbits GmbH, and Marshall Bernal of Toreno Information Solutions) the survey was sent to approximately 140 Atlassian User Group Team Leads around the world. Of this latter group, I received back 14 responses from all continents having Atlassian User Groups.

In some cases, I followed up by email with the survey participant.

 

A preliminary presentation of this study was made to the Toronto Atlassian User Group on Monday August 13, 2018. That presentation generated additional valuable insights.

Table 1

Survey Respondents

Name AUG
Philipp Sendek Brainbits GmbH
Marshall Bernal Toreno Information Solutions
Susan Hauth Toronto AUG
Fernando Ducloux Manilla AUG
Danny Harris Newcastle upon Tyne AUG
Katarzyna Olchawa Warsaw AUG
Maxim Yemelyanov Latvia AUG
Mike Brosnan Galway AUG
Marat Kiniabulatov Ufa AUG
Tim Zachararias Houston AUG
Victor Florin Pana Bucharest AUG
Shoba Cardoza UAE AUG
Fabio Genovese Bologna AUG
Brett Wilson Vietnam AUG
Boriana Todorova Sofia AUG
Anonymous x 2

 

Table 2

Survey Questions

Question
1)      How do you approach the use of Groups and Roles and Permission Schemes in your projects?
2)      Do you have standard rules or guidelines you use when determining how/where/when to use a group?
3)      Are these rules or guidelines based on your own experience or because of ‘client’ requirements?
4)      How do you build groups: broad with a large number of users, or narrow with a very limited number of users?
5)      When do you use a User in place of a Group?
6)      How do you use a Project Role? Tightly tailored for a single project? Broad as possible so as to be reused in other projects?
7)      What makes you decide to give a project permission to a Group rather than a Role?
8)      When do you (or do you) assign a User to a Role rather than a Group?
9)      What do your clients want when it comes to Users, Roles, and Groups? Why?
10)  What is your approach to the Default Permission Scheme?
11)  How much do you deal with Active Directory and LDAP? How much does it influence how you work with Users and Groups in Jira?

 

Summary of Survey Findings

There are three general summary findings with regards the Survey:

  • Open or Closed: It Depends
  • How multiple permission schemes impact performance
  • Chicken or Egg or Active Directory

 

Open or Closed: It Depends

An Open Jira is defined as a Jira instance where the Jira defaults are in extensive use and there is little in the way of custom Groups, Project Roles, or Permission Schemes. The purpose of an Open Jira instance is to give all of its licensed users as much visibility and access to Jira Projects and Issues as possible. A Closed Jira has many customized Groups, Roles, and Permission Schemes. The purpose of the Closed Jira instance is to highly restrict the visibility and access to Projects and Issues for security reasons.

Two variables appear to have a significant impact as to how ‘open’ or ‘closed’ a Jira instance will become. Those two variables are Risk and Complexity.

Degree of Risk

For the purpose of this study, Risk is defined two ways.

First is the degree to which unauthorized visibility or access to an Issue or Project will negatively affect the organization.

Second is the belief by the ‘client’ (internal or external) that the default permission scheme or ‘large’ groups / roles do not provide enough security.

The greater the risk (real or perceived), the greater the demand for a more secure system; which typically translates to more Groups, more Roles, and more Permission Schemes.

Degree of Complexity

Complexity is the number of clients and different types of Projects, Issue Types, or Workflows the organization manages.

The greater the degree of complexity, the greater the demand for a more secure system.

It is important to note that the number of licensed Users is not necessarily a strong indicator or Risk or of Complexity. An organization may have a large number of Users that deal with a limited number of Projects and Issue Types and where risk is seen as low. A call center with 1,000 Users dealing with one project and 3 appliance products Issue Types for example.

Diagram 1

Degree of Risk and Complexity Matrix

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In Diagram 1, a Jira instance occupying the lower left quadrant (small Risk and small Complexity) is more likely to be using the Jira defaults, or to have a more ‘open’ environment.

Those Jira instances occupying the other three quadrants are likely to be using a more ‘closed’ Jira environment.

This is not to say that there are three times as many closed systems as open. Indeed, the study (albeit a small sample size) appears to show an almost equal balance between open and closed Jira instances.

 

How multiple permission schemes impact performance

The survey attempted to determine the extent to which Jira Admins used the Default Permission Scheme versus those that used multiple schemes.

One interesting reason for using only the Default Permission Scheme came from a number of recipients who indicated that using multiple permission schemes resulted in a slowdown in performance in Jira. Philipp Sendek of brainbits GmbH provides the answer to this issue.

This seems mainly related to JQL searches that don’t include a project, as the search processor needs to check all permission schemes and issue security schemes for what the searching user is allowed to see.


https://confluence.atlassian.com/jirakb/understanding-jql-performance-740263450.html

And while this can be an issue, it’s always important to consider the amount of issues and the system that’s hosting Jira.

Nevertheless, I wouldn’t go too strict with permission schemes, as it’s certainly inevitable to have individual permission schemes

Philipp Sendek

Respondents also seemed to be equally divided between those using the Default Permission Scheme and those using multiple schemes.

There were two predominant reasons for solely using the Default scheme. First, the organization had little complexity and small perceived risk. Second, the Jira Admins had enough confidence in the precision of their Groups and Project Roles to be able to use the one permission scheme.

Those that used multiple schemes appeared to do so for two reasons. First, while a single permission scheme should be sufficient (assuming well defined Groups and Roles), some organizations prefer a ‘belt and suspenders’ approach (well defined Groups and Roles and a distinct permission scheme for the project).  Second, in many cases the Client is not comfortable with using a single permission scheme. Either the Jira Admin is unable to clearly explain why a single permission scheme is sufficient, or the Client wants the insurance that the ‘belt and suspenders’ method provides.

 

Chicken or Egg or Active Directory

Surprisingly, there was little consistency in the manner of creating Groups and Project Roles. Some liked large Groups and Project Roles, others like small, well defined, Groups and Roles, others a mix of both. In addition, some created Project Roles first and then Groups, while others did just the opposite: Groups first then Roles. All had logical reasons for their methodology.

Active Directory (AD) does seem to play a role in the creation of Groups and Roles. In many cases, AD tends to drive a more holistic approach to defining Groups and Roles. Based on responses it appears that the creation and naming of Groups and Roles in an AD organization aligns closely with the Group names in the Active Directory. In addition, in a number of cases, there is an attempt to align Jira Project Roles with the organization’s job descriptions (which in turn tend define the AD Group names).

Finally, a couple of respondents worked in ISO certified organizations. In these cases, the ISO certification required strict definition of job roles in the organization, which in turn are translated into Groups in AD. The AD groups then defined the Jira Groups and Project Roles as well as the names for those Jira Groups and Roles.

 

Conclusion

When creating the survey, it was my expectation that I would receive responses that were fairly consistent. However, the one word that seems most appropriate when describing the study responses is ‘inconsistency’. Bottom line: There is not a standard approach to the creation and management of Jira Groups, Roles, and Permission Schemes.

This is not meant as a negative. The strength of Jira is its flexibility, its ‘Swiss Army Knife’ capability. This flexibility means that it can suit diverse and disparate business requirements.  Those needs can demand different approaches to Groups, Roles, and Permission Schemes.

It is also fair to say that the creation and management of Jira Groups, Roles, and Permission schemes appears to be more of a practiced art than of a trained science. It appears (anecdotally) that most Jira Admins learn the software through one-on-one training by a colleague or by working with Jira and reading documentation. Consequently, the Jira Admin will typically use a procedure to manage Groups, Roles, and Permission Schemes that is consistent with how they learned the software.

It also appears (anecdotally) that Jira Admin skill experience and skill level is, in many ways, driven by the business requirements of the client. A client that is comfortable with a completely open Jira instance, does not force the Jira Admin to expand his skills. On the other hand, a business that is ISO compliant, has Active Directory, and deals with highly sensitive information forces the Jira Admin to develop her Jira skills to meet those demanding needs.

To conclude, how Jira Groups, Project Roles, and Permission schemes are managed is primarily dependent on the business requirements of the organization along with the skill set of the Jira Admin and the procedure used by that Admin.

 

Key Take Aways

There are three key take-aways from this study.

  • You, like me, may have been wondering if your approach to managing Groups, Roles, and Permission Schemes was the ‘right way to do it’. As we have seen there is no defined best practice. To use an analogy, there is more than one way to get to Buffalo. As long as you get there, that’s usually all that matters.
  • If you are switching organizations you will need to understand whether it is an Open or Closed Jira culture. If your experience is with an Open Jira and you are going to a Closed environment, you may run into a steep learning curve in order to understand the intricacies of that organization’s Jira instance. Conversely, if you come from an organization where Jira is tightly locked down and you move to an Open system, you will likely need to restrain your natural inclination to ‘make things a little more secure’.
  • Again, if you are switching organizations, it is important to understand the Jira culture to which you are moving. You may be in the ‘Group first, then Role’ camp, and you are moving to an organization that is ‘Role first, then Group’. If it doesn’t really matter which is first, then is it worth trying to convert your new home to your preferred methodology?

 

Responses

This next section contains respondents’ answers.  The responses are in a table format with each cell containing the answer from one individual. All responses are confidential. Please be aware that with many of the respondents English is a second language. I have corrected obvious spelling mistakes, but otherwise have not edited any responses.

 

Table 3

Survey answers

How do you approach the use of Groups and Roles and Permission Schemes in your projects?
Always use groups to define Roles, this way it’s much easier to manage several projects.

—-

Generally I tend to use only roles in my permission schemes

—-

To build an entirely new JIRA Project, I start by defining the necessary Project Roles within the limits of the project and the organization. As an example, a software development organization should mirror the team roles required to deliver the products defined by the project, Developers, Project Managers, Product Owners, Quality Assurance, and Third Parties. Once Project Roles have been established, I am able to sort the Project Permissions into each Project Role. I exclusively use Project Roles over User Groups as Project Roles can be restricted on a per user / per project basis, e.g. Schedule Issues Permission needs to be given to the Project Manager Project Role however there are different PMs for different projects.

—-

I use global roles and groups as there’re not that much of projects going on in our teams. We got basic permission scheme, and it’s rarely needed to actually restrict people from editing, deleting (well, deleting is one thing we restrict everyone). Guidelines based on projects experienced and worked on. Groups are used depending on factors, such as necessity and how often it’s needed to invoke rules for that group. Basically as the project dictates.

—-

Use roles everywhere, and leave it up to the project admin to decide who should be included in their project. Use groups to regulate access to the applications

—-

We have two roles agreed on our project: standard developers and admins. Admins are PO&SM, other – developers. All projects are open to other team members

—-

For Permission Schemes in JIRA projects use always role not group or users. Administrators of the project have a chance to add or remove groups, users in dedicated role. It is good idea because i don’t need to remember which group or users are in which scheme. Project admin is responsible to give or remove permissions by adding or remove group / users in role. System or JIRA administrator just have a few permissions schemes where for example role Product Owner can manage sprints, create issue, comment issue, set a fix version etc. As everybody know… less schemes is better. Keep everything very simply. It is big deal when you have got big instance (about 8k users).

Oh.. and i am using jira groups to manage licences for Bitbucket and fisheye crucible… artifacrory etc…

ah.. i forgot you should wrote about issue security (groups helps) and conditions and validators in workflow based on roles and groups!

—-

I use my experience, my point of view to configure following the specific situation. For me a pattern doesn’t exist to create a perfect configuration. So, as a modern craftsman, a create my solution 🙂

If in the specific scenario I need use role, I use role. If I don’t need, I don’t use it.

It depends of the situation, the customer, the need, and so forth

—-

As much as possible I would always delegate role based permissions to Active Directory security groups. Best practice I’ve found is – Define acronym for roles, e.g. LD – lead developer – DEV – Developer, RO – Read Only – Use numbers for project identifiers. If your company has a directory of Applications, use that identifier as a group name –

Use LDAP Role Groups

—-

In general, here is how we approach these features:

Groups: Defined as individually as possible, not broadly, and given verbose names and descriptions that define what they do.

Roles: Groups are generally tied one-to-one to a project role.  Example, “Jira Quality Department Administrators” group ties to the Quality Department project, for the Administrator role.

Permission Schemes: Kept as default as possible, changes that are made generally only apply to a single project.

—-

Groups v Roles… My preference is to always use groups where applicable as it is generally easier to manage. At the start of the project I would setup the various Groups needed e.g. Customer, Developer and or Testing, Admin. I would then assign the Groups to Project Roles. If there are ‘special cases’ related to this project only, I may consider adding them as individual users (but will not be best practice). I would ensure that the Groups are aligned to the correct permission scheme e.g. Customers may not be able to see specific fields. I would also ensure that the Project Roles align with this.

Regarding workflows & permission schemes, I tried not to stray too far from the defaults and would try to limit the number of both in the system.

—-

Do you have standard rules or guidelines you use when determining how/where/when to use a group?
No rules.  But as soon as there starts to be more than 5 individuals to a role or we need a filter/subscription, then we create a group.

—-

It depends, normally I try to create them as broad as possible. In general I have a rule that if you want a group with less than 10 users, then you don’t actually need that group and can handle individual permissions.

—-

I saw a few rules for manage groups. First, don’t use jira-users (groups which can login to JIRA, every user) everywhere. Of course there is difference if you have got LDAP users groups synchronized or when you have got only local groups. If you have got only internal local groups you have got control and possibility to manage it and… it can be good but not always. You can have different rules depends on this who manage groups (Active Directory admin or You – JIRA admin).

 

Don’t give jira-users (groups for login to JIRA) roles in your project (you don’t want to give permissions for accountant, developers, all scrums masters, security specialists, sales managers, external users, business users, all technical accounts etc.

 

Create ticket for JIRA supports team to create dedicated group if you need it to set up permissions, subscription, share a filter.

 

Use short name for groups if you can.

 

Use the same group for role, shared objects, agile boards etc. Remember that you can not rename group, so try to take universal groups. Example, i have got group named “Kasia’s Team” and after 3 months Kasia leave the company… now we must “rename” group to “Tomek’s Team”.

 

Replace one group to another can be hard (Tempo plugins, shared filters and dashboards, JQL – every filters used groups). Better to name group “UX Team” or “Android Team” without last name one of team member. Users (especially) project admins sometimes wants to see who is in groups. You can use plugins or develop own solution.

—-

We actually don’t use groups and roles very much anymore. We used to use them to segregate access between projects, but found it was better for them to be open for the most part so people can see all the information.

—-

Yes, only use User Groups with regards to add-on project permissions, e.g. Tempo Timesheets has an additional project permission to view billable hours and a Financial Team may want to only access that relevant information.

—-

Yes, set of role based groups linked to project roles

Indeed, our rule for creating groups, is they are created upon creation of the project.  The groups are created which encapsulate the project name, as well as the role name.

—-

Are these rules or guidelines based on your own experience or because of ‘client’ requirements?
Personal experience

—-

Own experience … because customers where asking for it

—-

Rules and guidelines are following client security and other requirements.

—-

It comes from managing Jira with hundreds of projects

—-

Both, my experience for keeping single users out of permission schemes as this is problematic and internal stakeholder requirements surrounding the access of relevant information.

—-

Entirely on own experience.  Generally, the customer simply ‘wants this to work’.  You could name groups things like ‘Bananas’ or ‘Peaches’.  Customers don’t care as long as managing the system, going forward, will be easy for someone to manage.

—-

How do you build groups: broad with a large number of users, or narrow with a very limited number of users?
Both – We rely on “All Staff Global” group for much of the general access.  Clients are broken down by individual groups

—-

I build groups with a very small number of users in mind, e.g. a Financial Team only requires access to certain pieces of information across the entire portfolio of projects.

—-

Groups are broad in general such as jira-software-users …

A very big groups are hard to manage. So if i have got this kind of group it is good to find a functionality which user must have. Example: i have got groups for every department (Dep.A Dep.B Dep.C Dep.XYZ) and if someone wants to have posibility to work on internal issue (Tempo Timesheet plugin) i had to give him / her good group Dep.B Problem dosnt exist for you if you delegated groups management to your Active Directory admins.

—-

Project scoped role based AD groups

—-

We have several groups, which makes project management quite simple. We have a large directory (LDAP), that represents our entire staff, and different types of groups: Role, Teams, location. Where for example, Team1, Team1_management, Team1_london; Team1_stockholm, etc. Then we have Allusers, Office_London, Office_stockholm, Sales_London, Sales_stockholm, etc Then Roles, LineManagers, Business, IT_Operatos, IT_Development, Sales etc. All this makes project role management quite easy. Every time there’s a new employee, it automatically falls into a particular role, and the groups are automatically populated. Automation is very important.

—-

Exceedingly narrow – we attempt to never ‘reuse’ a group, because we see that idea getting us into trouble.  It always winds up being that a customer will develop more requirements to restrict access and divide roles, than a customer simply saying ‘all users need to have access to these things’.

—-

When do you use a User in place of a Group?
When you only have 3-5 people in a single project that need a specific role.  Won’t bother with a group.

—-

We don’t

—-

Never

—-

I use user when group will have only one user. Remember that you can not make subscription for users (you can set up it for yourself or group).

—-

when basically we have a need for an individual for an override (temporarily) group permissions.

—-

If the “group” does not meet the minimum numbers of persons or if from a group of x persons, only a selected few should see the content.

 

Almost never.  Once a project goes ‘mainstream’ in the organization, we always wish there was a group that was setup to encapsulate all of the users.

—-

How do you use a Project Role? Tightly tailored for a single project? Broad as possible so as to be reused in other projects?
Broad as possible to be reused in other projects.

—-

Broad. Yes, Project Roles should be used in this way as they are global roles applied to all JIRA Projects.

—-

Broad definition of role with an agreement company wide – such as ‘Developer’, ‘Validator’, ‘Approver’ …

—-

Broad as possible

—-

There’s a little bit of both. There’re tight projects, like HR or Finance, where security is critical. Other projects, like IT Support is wide open.

—-

Roles should named also universal as you can. You don’t need many roles for permissions. And remember roles are for all projects. And… again example. Some plugins add roles for JIRA project. JIRA Service Desk add Administrators role and it is for project admins confusing because they don’t see difference between Administrator and Administrators role.

—-

When spinning a new project, we generally try to keep the roles as default as possible, using what was provided out-of-the-box.  If we do wind up creating a custom role, it will, in general, be tightly tailored to the individual project, and probably not reused.

—-

What makes you decide to give a project permission to a Group rather than a Role?
If I’ve run out of roles in my project (it happens).  Or the use of jira-administrators group to do things like Admin, Delete, delete all worklogs.  Sorta of those super powers for the super admins.

—-

Only 2 instances of using User Groups within Project Permissions as the requirements are well defined and narrow.

—-

I always give a role. Project administrator can add group to project role. I have got shared permissions schemes. If project admin needs a new group – just create ticket.

—-

We don’t

—-

If just a part of the users from a Role should be able to have a certain permission (also given the fact that I use roles as broad as possible, so there is no room to use other roles for the permission, rather than a group).

—-

ideally – only with roles, roles are used everywhere notifications, workflows, issue security schemes, permissions …

—-

Narrow, single use specialization.  A client will have a requirement such as ‘Well, only this user will only ever need to do X in this project’.

>Even then, we try to convince the organization to create up a group, because in our experience, it starts out as one user, but will wind up being more.

—-

When do you (or do you) assign a User to a Role rather than a Group?
When it comes to adding a single user to a permission, I would tend to add him/her to a role or a group instead, as a group can be properly named to resemble the permission that comes with it.

We don’t

—-

Yes, users are assigned to Project Roles so that each Jira Project is individual.

—-

Always unless the whole user community needs to have access to a certain set.

—-

When there are so few it doesn’t make sense to go through a hassle of a group.  And if those users don’t belong together in other projects, there’s no point in a group.  If I can’t reuse the group…I don’t bother

—-

There is no right answer here, as to many of the answers from above. It all depends on what data is “stored” in your JIRA and who should see it. If you have internal and external employees in your jira and so on. Like I’ve said, if you plan to add less than 10 persons in a role, then you don’t need a role

—-

I do it very, very rarely… when i have got dedicated technical account for example default internal account to create or comment issue via e-mail (incoming mails).

—-

Almost never; only when there is a single exception that needs to be made.  And even at that, it is well-documented.

—-

What do your clients want when it comes to Users, Roles, and Groups? Why?
Add users to groups, help to understand jira permissions, check what can or cannot a user…

—-

Transparency

—-

I like the idea that I do as much as possible with Roles, because then my project admins can control that destiny.  If I used users, groups into say permissions then the project admin can’t manage that.

—-

Customers want to be able to access relevant information quickly and efficiently with security in mind.

—-

We have strict compliance, it’s not customer choice. We provide the tools for Customers to handle groups, and request new ones if needed.

—-

Ease of management, and transparency.  When a customer looks at a role, or group and see the members, they want to have a good idea about what those users can and can’t do inside that project.

—-

What is your approach to the Default Permission Scheme?
I use it as much as possible because having multiple permission schemes impacts performance.  Unfortunately my users think otherwise.  So I try and do a permissions compare to see if i can combine

—-

I have defined a permission scheme for 2 project types, because the permission scheme utilizes Project Roles each Project’s access is tailored.

—-

All authorization is delegated to AD security groups

—-

We rather not use it. We have a couple options, and we try to stick to those. It’s worked great so far.

—-

Use roles, ensure that for the delete options only the admin roles have them or the creators of the content.

—-

I have got a few default permissions schemes. Different for developers team project, business project, service desk, dedicated strange projects.

—-

Don’t touch it, use it for as many projects as possible, and if modification is needed, make a copy of it, name it congruent to the project.

—-

How much do you deal with Active Directory and LDAP? How much does it influence how you work with Users and Groups in Jira?
It’s a completely different approach due to our ISO9001 documentation:

In our JIRA, Confluence as well as our Active Directory, we have a group for every role in the company, such as role_ceo, role_employee, role_intern, role_atlassianconsultant, role_itadmin.

These roles are also all added as project roles in JIRA and the respective group is added to it

—-

a necessary evil.   We are trying to figure out a way that the groups for AD and the groups for jira are separate and the two shall not meet.

—-

I administer the company LDAP, I’ve taken the time to write scripts to automate the entire user/group management, and have a team that process requests.

—-

I am using local groups but users are synchronized via AD, so i am managing groups.

—-

Good practice is to add people to projects only via groups but most of the time we add persons as it’s easier to manage JIRA groups than AD groups.

Answering your questions brought me to an understanding that we need to deal with group situation on the project – currently it’s not regulated and we need to abandon current practice and do everything via AD groups only. Currently all is assigned by adding people directly to project roles.

—-

Regarding adding users, would use a SSO where possible (Crowd or Google).

—-

Heavily – if the organization uses an LDAP or AD system, all groups, and the membership of these groups should be represented in that system.  It makes the reporting and management of the organization much easier.  As far as how it influences how the system works, it just means that when we want to create groups, and add users to groups, those functions may be done by someone else in the organization, not necessarily by the ‘Jira’ administrator

—-

Fortunately, I have not had to integrate with AD or LDAP yet

—-

 

 

—-End Document—

Rynder Roy Klomp

Toreno Information Solutions

TorenoIS.com

Leave a Reply