Securing your JIRA 4

Exclusive offer: get 50% off this eBook here
JIRA 4 Essentials

JIRA 4 Essentials — Save 50%

Track bugs and issues and manage your software development projects with this JIRA book and eBook

$35.99    $18.00
by Patrick Li | June 2011 | Enterprise Articles Java

As an information system, JIRA is all about data. It should come as no surprise to you that security plays a big role in JIRA not only to ensure that only the right people get access to the data, but also to maintain data integrity by preventing accidental changes.

By the end of the article by Patrick Li, author of JIRA 4 Essentials, you will have learned:

  • How to utilize user management features in JIRA
  • About JIRA's permission hierarchy
  • About general access control in JIRA
  • How to manage fine-grained permission settings

 

JIRA 4 Essentials

JIRA 4 Essentials

Track bugs and issues and manage your software development projects with JIRA

        Read more about this book      

(For more resources on this subject, see here.)

Before we delve into the deep end of how JIRA handles security, let's first take a look at how user memberships are managed.

Users

In any information system, for users to access the system, they need to have an account. In JIRA, each user needs to have their own user account for them to access the data. Each user is identified by their username, which cannot be changed after account creation.

User Browser

JIRA administrators can manage users centrally from the User Browser.

  1. Log into JIRA as a JIRA Administrator.
  2. Click on Administration from the top menu bar.
  3. Select User Browser from the left panel to bring up the User Browser page.

From the User Browser, you will be able to see a list of all the users in JIRA. The User Browser also provides you with search capabilities. You will be able to search for users that fit criteria such as username, full name, e-mail address, and group association. By default, the results will be paginated to show twenty users per page, but you can change this setting to show up to one hundred users per page. When dealing with large deployments with hundreds of users, these options will become extremely useful to quickly find the users you need to manage.

Other than the ability for you to effectively search for users, the User Browser also serves as the portal for you to add new users to JIRA, and manage user's group/role associations.

Adding a user

There are two ways for new user accounts to be created in JIRA. The first option is to have centralized management where only the JIRA administrators can create and maintain user accounts. This option is applicable to most private JIRA instances designed to be used by an organization's internal users.

The second option is to allow users to sign up for accounts themselves; this is most useful when you are running a public JIRA instance where manually creating user accounts is not feasible because of the volume of work. We will be looking at how to enable public signup options in later sections, for now we will examine how administrators can create user accounts manually.

  1. Browse to the User Browser page.
  2. Click on the Add User link. This will bring you to the Create New User page.
  3. Provide a unique username for the new user. The username cannot be changed once it is set.
  4. Specify the password, full name, and e-mail address for the user.
  5. Optionally check the Send Password Email option if you have a SMTP server configured for JIRA. If checked, JIRA will send an e-mail to the user with a link for them to reset their password.
  6. Click on the Create button to create the new user.

Enabling public signup

If your JIRA instance is public, for example, as a public support system, creating user accounts individually as explained earlier will become a very demanding job for your administrator. For this type of JIRA setup, you can enable public signup to allow users create accounts themselves.

To enable public signup in JIRA:

  1. Log into JIRA as a JIRA Administrator.
  2. Click on Administration from the top menu bar.
  3. Select General Configuration from the left panel to bring up the General Configuration page.
  4. Click on the Edit Configuration link at the bottom of the page.
  5. Select Public for the Mode field.
  6. Click on the Update button to apply the setting.

Once you have set JIRA to run in the Public mode, users will be able to sign up and create their own accounts from the login page.

Securing your JIRA 4

As we will see in the later section, Global Permissions, once a user has signed up for a new account, he/she will automatically join groups with JIRA users' global permission.

If you have set JIRA to run in Private mode, only the administrator will be able to create new accounts.

Enabling CAPTCHA

If you are running JIRA in Public mode, you run the risk of having automated spam bots creating user accounts on your system. To counter this, JIRA provides the CAPCHA service where potential users will be required to type in a word represented in an image into a text field. To enable CAPTCHA service:

  1. Browse to the General Configuration page.
  2. Click on the Edit Configuration link at the bottom of the page.
  3. Select On for CAPTCHA on signup.
  4. Click on the Update button to apply the setting.

Now when someone tries to sign up for an account, JIRA will present them with a CAPTCHA challenge that must be verified before the account is created.

Securing your JIRA 4

Groups

Groups are a common way of managing users in any information system. A group often represents a collection of users, usually based on their positions and responsibilities within the organization. In JIRA, groups provide an effective way to apply configuration settings to users, such as permissions and notifications.

Groups are global in JIRA, which is something that should not be confused with Project Roles (discussed later). This means if you belong to the jira-administrators group, you will always be in that group regardless of which project you are accessing. We will see in later sections how this is different from project roles and their significance.

One important point to keep in mind is that a group association does not cascade in JIRA. For example, just because a user is in the jira-developers group does not mean he/she will have the privileges of the jira-users group.

Group Browser

JIRA administrators can manage groups centrally from the Group Browser.

  1. Log into JIRA as a JIRA Administrator.
  2. Click on Administration from the top menu bar.
  3. Select Group Browser from the left panel to bring up the Group Browser page.

Similar to the User Browser, the Group Browser allows you to search, add, and configure groups within JIRA.

JIRA comes with three default groups. These groups are created automatically when you install JIRA.

Securing your JIRA 4

Out of the three groups, jira-administrators and jira-users are of most significance. As we will see later in this chapter, by default, jira-administrators are given the global permission to administer JIRA while jira-users are only given permission to access JIRA. You can, as we will learn, change this default behavior so your custom groups have the same permissions.

Adding a group

Other than the three groups that come by default with JIRA, you can create your own groups. It is important to note that once you have created a group, you cannot change its name. Make sure you think about the name of the group carefully before you create it.

  1. Browse to the Group Browser page.
  2. Specify a unique name of the new group in the Add Group section.
  3. Click on the Add Group button to create the new group.

After a group has been created, it is empty and will have no members. It will also have no configuration settings such as the permissions applied.

Editing group membership

It is often that people move around within an organization, and JIRA needs to be kept up-to-date with the movement.

From the Group Browser, there are two ways to manage group membership. The first option is to manage the membership on per-group level, and the second option is to manage several groups at the same time. Both options are actually very similar, so we will be covering both at the same time.

To manage individual groups:

  1. Browse to the Group Browser page.
  2. Click on the Edit Members link for the group you wish to manage the member for. This will bring you to the Bulk Edit Group Members page.

To manage multiple groups:

  1. Browse to the Group Browser page.
  2. Click on the Bulk Edit Group Member link. This will bring you to the Bulk Edit Group Members page.

You will notice that both options will take you the same page. The difference is if you have chosen the individual group option, JIRA will auto select the group to update, and if you have chosen the bulk edit option, no groups will be selected. However, regardless of which option you have chosen, you can still select one or all of the groups to apply your changes to.

To update the membership in one or more groups:

  1. Browse to the Bulk Edit Group Members page.
  2. Select one or more groups to update.
  3. Select users from middle box and click on the Leave button to take users out of the groups.
  4. Specify users (by typing usernames) in the right-hand box and click on the Join button to add users into the groups.

Deleting a group

If a group has become redundant, you can remove it from JIRA.

  1. Browse to the Group Browser page.
  2. Click on the Delete link of the group you wish to remove. This will take you to the Delete Group page.
  3. Click on the Delete button to permanently remove the group.

Once you have removed the group, it will automatically remove all the users who previously belonged to it.

Project roles

As we have seen, groups are collections of users and are applied globally. JIRA offers another way of grouping users, which is applied on the project level only.

Securing your JIRA 4

Project role browser

Similar to users and groups, project roles are maintained centrally by the JIRA administrator through the Project Role Browser. There is a slight difference however, since project roles are specific to projects, JIRA administrators only define what roles are available in JIRA and their default members. Each project's administrators (discussed in later sections) can further define each role's membership for their own projects, overriding the default assignment. We will first look at what JIRA administrators can control through the Project Role browser and then look at how project administrators can fine-tune the membership assignment later.

To access the Project Role Browser:

  1. Log into JIRA as a JIRA Administrator.
  2. Click on Administration from the top menu bar.
  3. Select Project Role Browser from the left panel to bring up the Project Role Browser page.

Securing your JIRA 4

Adding a project role type

The list of project roles is managed by the JIRA administrator. As an administrator, you can create new role types which can then be used by project administrators for their projects.

To create a new project role:

  1. Browse to the Project Role Browser page.
  2. Specify a unique name for the new project role in the Add Project Role section.
  3. Specify an optional description.
  4. Click on the Add Project Role button to create the project role.

Once you have added a new project role, it will appear for all the projects.

Editing a project role

You can update a project role's name and description.

  1. Browse to the Project Role Browser page.
  2. Click on the Edit link for the project role you wish to update. This will take you to the Edit Project Role page.
  3. Specify a new name and description.
  4. Click on the Update button to apply the changes.

Deleting a project role

Existing project roles can be deleted if they are no longer used.

  1. Browse to the Project Role Browser page.
  2. Click on the Delete link of the project role you wish to remove. This will bring up the Delete Project Role page.
  3. Click on the Delete button to remove the project role.

Managing default members

As new projects are created in JIRA, often those projects share a similar security requirement. It becomes desirable to have default members assigned to the project roles when new projects are created.

For example, by default, users in the jira-administrators group will have the Administrators project role. This increases the efficiency of security setup by creating a baseline for new projects, but also offers the flexibility to allow modifications to the default setup to cater for unique requirements.

  1. Browse to the Project Role Browser page.
  2. Click on the Manage Default Members link for the project role you wish to remove. This will take you to the Edit Default Members for Project Role page.

From this page, you will see all the default members assigned to the selected project role. Default members can be logically assigned project roles based on group setup. Users can be useful when you have exceptional cases, such as a lead developer who should have the Developers role in all software development projects.

To add a default user/group for the project role:

  1. Click on the Edit link for the default member option (either user or group).
  2. Use the user picker/group picker function to select the users/groups you wish to assign to the project role.
  3. Click on the Add button to assign the role.

Once added, any new project created will have the specified users/groups assigned to the project role. It is important to note that after you have set default members, only new projects will have the settings applied. Existing projects will not retrospectively have the default members applied.

Default members is an efficient way for JIRA administrators to assign project role members automatically without having to manually manage it for each new project as they come in. After a project has been created, it becomes the responsibility of the project administrator to maintain the project's role membership, which we will be looking at in the next section.

Assigning project role members

JIRA allows you to assign default members to projects when they are created. This might be sufficient for most projects when they start, but changes will often need to be made due to staff movements throughout the project life cycle. It is possible for the JIRA administrator to continue maintaining each project's membership, but it can easily become an overwhelming task. In most cases, since project roles are specific to each project, it makes sense to delegate this responsibility to the owner of each project.

In JIRA, an owner of a project is someone with the Administrators Projects permission. By default, members of the Administrators project role will have this permission. We will see how to manage JIRA's permissions in the later sections.

As a project administrator, you will be able to assign members to the various project roles for your project. You can assign roles from the project administration page.

  1. Log into JIRA as a user with Administrators project role for one or more projects. (By default, members of the jira-administrators group will have this role).
  2. Click on Administration from the top menu bar.
  3. Select the project you wish to manage the role members for. This will bring you to the Project Administration page.

    Securing your JIRA 4

  4. Click on the View Members link next to Project Roles. This will bring you to the Manage Project Role Membership page.
  5. Click on the Edit link for either Users or Groups for the project role you wish to configure. This will take you to the Assign Users/Groups to Project Role page.
  6. Use the user/group picker to search and select users/groups to assign to the project role.
  7. Click on the Add button.

The users and groups assigned to the project role will be for the current project only. You will have to reconfigure the members again for other projects. This way, project role members are maintained separately for each project.

Securing your JIRA 4

JIRA 4 Essentials Track bugs and issues and manage your software development projects with this JIRA book and eBook
Published: May 2011
eBook Price: $35.99
Book Price: $59.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on this subject, see here.)

JIRA permission hierarchy

JIRA manages its permissions in a hierarchical manner. Each level is more finegrained than the one above it. For a user to gain access to a resource, for example, to view an issue, he/she needs to satisfy all three levels of permission (if they are all set on the issue in question).

  • JIRA Global Permission: Controls overall access rights to JIRA. For example, who can access JIRA.
  • Project Level Permission: Controls project level permissions.
  • Issue Level Security: Controls view access on a per issue level.

We will look at each of the permission levels and how you can configure them to suit your requirements, starting from the most coarsely grained permission level- Global Permissions.

Global Permissions

Global permissions, as the name suggests, is the highest permission level in JIRA. These are permissions applied globally across JIRA, controlling broad security levels such as ability to access JIRA and administer configurations.

Since they are not very specific permissions, global permissions are applied to user groups rather than users. The following table lists all the permissions and what they control in JIRA.

Securing your JIRA 4

JIRA System Administrator versus JIRA Administrator

For people who are new to JIRA, it is often confusing when it comes to distinguishing between JIRA System Administrator and JIRA Administrator. For the most part, both are identical, in that they can carry out most of the administrative functions in JIRA.

The difference is that a JIRA Administrator cannot access functions that can affect the application environment or network while a JIRA System Administrator has access to everything.

Although it is not necessary to have a separate role for both, it is sometimes useful to have one person overlooking general JIRA administrative tasks while have another with the ability to configure system-wide settings such as SMTP mail service, which is a system resource outside of the JIRA application. By default, the jira-administrators group has both JIRA System Administrators and JIRA Administrators permission.

The following list shows system operations that are only available to people with JIRA System Administrators permission.

  • Configure SMTP server details
  • Configure CVS source code repository
  • Configure listeners
  • Configure services
  • Configure where JIRA stores index files
  • Import data into JIRA from an XML backup
  • Export data from JIRA to an XML backup
  • Configure where attachments are to be stored on the file system
  • Access JIRA license details
  • Grant/revoke JIRA System Administrators global permission
  • Delete users with JIRA System Administrators global permission

Configuring Global Permissions

Global permissions are configured and maintained by JIRA administrators and JIRA system administrators (to grant JIRA System Administrator global permission).

  1. Log into JIRA as a JIRA Administrator.
  2. Click on Administration from the top menu bar.
  3. Select Global Permissions from the left panel to bring up the Global Permissions page.

Granting global permission

Global permissions can only be granted to groups. For this reason, you will need to organize your users into logical groups for global permissions to take effect. For example, you will want to have your internal users who will use JIRA to be placed in the jira-users group (the default group given the JIRA Users global permission).

  1. Browse to the Global Permissions page.
  2. Select the Permission you want to assign from the Add Permission section.
  3. Choose the Group to be given the permission.
  4. Click on the Add button to add the assignment.

The Group drop-down list will list all the groups in JIRA. It will also have an extra option called Anyone. This option includes users who are not logged in. You cannot select this option when granting JIRA Users permission, as JIRA Users is required to user to login and Anyone refers to users who are not logged in. For a production system, it is recommended not to grant any global permission to Anyone as this can lead to security and privacy concerns.

Revoking global permission

Global permissions can also be revoked. However, there are a few rules and restrictions you need to be aware of. They are as follows:

  • Both JIRA System Administrators and JIRA Administrators can revoke global permissions, but JIRA Administrators cannot revoke a JIRA System Administrator's global permission.
  • If you revoke JIRA Users permission, you are effectively disallowing the affected users from accessing JIRA (they will not be able to log into JIRA).
  • You will not be able to grant additional JIRA Users permission if you have exceeded the number of users permitted by your license.

To delete a global permission from a group:

  1. Browse to the Global Permissions page.
  2. Click on the Delete link for the group you wish to remove from the global permission. This will take you to the Delete Global Permission page.
  3. Click on the Delete button to remove the global permission.

JIRA has validation rules built-in to prevent you from accidentally locking yourself out by accidentally removing the wrong permissions. For example, JIRA will not let you delete the last group from JIRA System Administrators global permission, as doing so will effectively prevent you from adding yourself back, as only members of JIRA System Administrators can assign/revoke global permissions.

Project permissions

As we have seen, global permissions are rather coarse in what they control and are applied globally. Since they can only be applied to groups, it is rather inflexible when it comes to decide whom to grant the permissions to.

To provide a more flexible way of managing and designing permissions, JIRA allows you to manage permissions on the project level, which allows each project to have its own distinctive permission settings. Furthermore, JIRA allows you to grant permissions to users through a range of options, including:

  • Reporter: The user who submitted the issue
  • Group: All users that belong to the specified group
  • Single User: Any user in JIRA
  • Project Lead: Lead of the project
  • Current Assignee: The user currently assigned to the issue
  • User Custom Field Value: User specified in a custom field of type User custom field
  • Project Role: All users that belong to the specified role
  • Group Custom Field Value: Users within the specified group in a Group custom field

The list of permissions is also more fine-grained and designed more around controlling permissions on a project level. The only catch to this is the list is final; you cannot add new permission types.

Securing your JIRA 4

Even though the list cannot be modified, JIRA provides you with a very comprehensive list of permissions that will cover almost all of your permission needs.

As you probably have guessed, with this many permissions, it will be highly inefficient if you have to create them individually for each project you have. JIRA lets you define your permissions once and apply them to multiple projects, with permission schemes.

Permission scheme

Permission schemes, like other schemes such as notification schemes, are collections of associations between permissions and users or a collection of users. Each permission scheme is a reusable self-contained entity that can be applied to one or more projects.

Like most schemes, permission schemes are applied at the project level. This allows you to apply finely-tuned permissions for each project. Just like project roles, JIRA administrators oversee the creation and configuration of permission schemes, and it is up to each project's administrators to choose and decide which permission scheme to use. This way, it encourages administrators to design their permissions that can be reused based on common needs of an organization. With meaningful scheme names and descriptions, project administrators will be able to choose the scheme that will fit their needs the most, instead of requesting a new set of permissions to be set up for each project.

We will first look at how JIRA administrators manage and configure permission schemes and then how project administrators can apply them in their projects.

To start managing permission schemes:

  1. Log into JIRA as a JIRA Administrator.
  2. Click Administration from the top menu bar.
  3. Select Permission Schemes from the left panel to bring up the Permission Schemes page.

On the Permission Schemes page, you will see a list of all the permission schemes. From here, you will be able to create new schemes, edit and delete existing schemes, as well as configure each scheme's permission settings.

Adding a permission scheme

JIRA comes with a preconfigured permission scheme called Default Permission Scheme. This scheme is suitable for most simple software development projects. However, it is often not enough and it is usually a good practice to not modify the Default Permission Scheme directly, so you should create your own permission schemes.

  1. Browse to the Permission Schemes pages.
  2. Click on the Add Permission Scheme link. This will take you to the Add Permission Scheme page.
  3. Provide a meaningful name for the new permission scheme.
  4. Provide an optional description.
  5. Click on the Add button to create the permission scheme.

Securing your JIRA 4

For new permission schemes, all of the permissions will have no user associations. This means if you start using your new scheme without further configuring its permission settings, you will wind up with a project that nobody can access. We will look at how to configure permissions in later sections.

Editing a permission scheme

You can keep a permission scheme's name and description up-to-date. You will often need to do this after you have made a copy of an existing permission scheme. As we will see in the following section, when you copy a permission scheme, JIRA automatically generates a name for your new scheme.

  1. Browse to the Permission Schemes pages.
  2. Click on the Edit link for the permission scheme you wish to update. This will take you to the Edit Permissions Scheme page.
  3. Update the name and description with new values.
  4. Click on the Update button to apply the changes.

Deleting a permission scheme

Unlike some other types of schemes, you can delete permission schemes even if they are being used by projects.

  1. Browse to the Permission Schemes page.
  2. Click on the Delete link for the permission scheme you wish to remove. This will take you to the Delete Permission Scheme page.
  3. Click on the Delete button to remove the permission scheme

If you are deleting a permission scheme that is being used by one or more projects, JIRA will prompt you with the list of projects that are currently using the scheme. If you delete it, all the projects will be automatically updated to use the Default Permission Scheme. You cannot delete the Default Permission Scheme.

Copying a permission scheme

It is not always desirable to create permission schemes from scratch, as there are around thirty permissions you will need to set for a new permission scheme. JIRA allows you to easily clone existing permission schemes with the copy function.

  1. Browse to the Permission Schemes pages.
  2. Click on the Copy link for the permission scheme you wish to clone. This will immediately create a copy of the permission scheme with the name with Copy of appended to the front of the original scheme's name.

One good use of the copy function is to create a backup of an existing permission scheme before you make changes. It is sometimes good practice to name your permission schemes with a version number and every time you need to make a change, create a copy and increase the version number in the name. This way, it helps you to keep track of your changes and help you to roll back your changes if things do not work out as planned.

Configuring a permission scheme

Just like most other schemes in JIRA, you need to further fine-tune your permission scheme to make it useful.

  1. Browse to the Permission Schemes page.
  2. Click on the Permissions link for the permission scheme you wish to configure. This will take you to the Edit Permissions page.

From this page, you will be presented with a list of project-level permissions available, along with short descriptions for each, and the users, groups, roles, and so on that are linked to each of the permissions. You will notice that for the Default Permission Scheme, most of the permission options have default users linked to them through project roles. If you are looking at a new permission scheme, there will be no users linked to any of the permissions. This is your one page view of permission settings for projects and you will also be able to add and delete users.

Unlike some other schemes such as a notification scheme, which allows you to add additional options (through custom events), you cannot define new permissions for a permission scheme.

Granting a permission

Like a notification scheme, JIRA offers you a range of options to specify which users should have certain permissions. You can specify users through some of the most common options such as groups, but you can also utilize some advanced options such as selecting users specified in a custom field.

Again, you have two options to grant permissions to a user. You can add a specific permissions or multiple permissions at once. Both options will present you with the same interface and there is no difference between the two.

  1. Browse to the Edit Permissions page for the permission scheme you wish to configure.
  2. Click on the Grant permission link or the Add link for specific permission. This will take you to the Add New Permission page.
  3. Select the permissions you wish to grant to the user.
  4. Select the user option to specify whom to grant the permission to.
  5. Click on the Add button to grant the selected permission.

An option like User Custom Field Value is a very flexible way of allowing the end-users control access. For example, you can have a custom field called Editors, and set up your Edit Issues permission to allow users specified in the custom field to be able to edit issues.

The custom field does not have to be placed on the usual view/edit for the permission to be applied. For example, you can set the custom field to appear on a workflow transition called Submit to Manager, and once the user has selected the manager, only the manager will have permission to edit the issue.

Revoking a permission

You can easily revoke a permission given to a user.

  1. Browse to the Edit Permissions page for the permission scheme you wish to configure.
  2. Click on the Delete link for the permission you wish to revoke. This will take you to the Delete Permission page.
  3. Click on the Delete button to revoke.

When you are trying to revoke permission to prevent users from gaining certain access, you need to make sure that there are no other user options granted to the same permission that might be applied to the same user. For example, if you have both Single User and Group options set for the Browse Projects permission, you will need to make sure to revoke the Single User option and also make sure that the user does not belong to the Group selected, so that the user does not have access via their group's permission setting.

Applying a permission scheme

We have gone over how permission schemes can be selected by project managers to set permissions for their projects. Now we will look at how to apply the scheme to your projects. The process will feel familiar; permission schemes are applied to projects in the same way as notification and workflow schemes.

  1. Log into JIRA as a project administrator.
  2. Select the project(s) that will be using the permission scheme.
  3. Click on the Select link for Permission Scheme. This will bring up the Associate Permission Scheme to Project page.
  4. Select the permission scheme to be used.
  5. Click on the Associate button.

Permission schemes are applied immediately and you will be able to see the permissions take effect.

JIRA 4 Essentials Track bugs and issues and manage your software development projects with this JIRA book and eBook
Published: May 2011
eBook Price: $35.99
Book Price: $59.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on this subject, see here.)

Issue security

We saw how JIRA administrators can restrict general access to JIRA with Global Permissions, and what project administrators can do to place permissions on individual projects through Permission Schemes. JIRA allows you to go down yet another level to allow ordinary users to set security level on the issues they are working with, with Issue Security.

Issue Security allows users to set view permission (not edit) on issues by selecting one of the pre-configured issue security levels. This is a very powerful feature as it allows the delegation of security control to the end users and empowers them (to a limited degree) to decide who can view their issues.

On a high level, issue security works in a similar way as permission schemes. A JIRA administrator will start by creating and configuring a set of issue security schemes with the security level set. Project administrators can then apply one of these schemes to their projects, which finally allow the users (with Set Issue Security permission) to select the security levels within the scheme and apply that to individual issues.

Issue security scheme

As explained earlier, the starting point of using Issue Security is the Issue Security Scheme. This is the responsibility of the JIRA administrator to create and design the security levels so they can be re-used as much as possible.

  1. Log into JIRA as a JIRA Administrator.
  2. Click Administration from the top menu bar.
  3. Select Issue Security Schemes from the left panel to bring up the Issue Security Schemes page.

Adding an issue security scheme

JIRA does not come with any predefined issue security schemes, so you will have to create your own from scratch. To create a new issue security scheme:

  1. Browse to the Issue Security Schemes page.
  2. Click on the Add Issue Security Scheme link. This will bring up the Add Issue Security Scheme page.
  3. Provide a meaning name for the new scheme.
  4. Provide an optional description.
  5. Click on the Add button to create the new issue security scheme.

Since an issue security scheme does not define a set of security levels like a permission scheme, you will need to create your own set of security levels right after you have created your scheme.

Configuring an issue security scheme

Unlike permission schemes that have a list of predefined permissions, with issue security schemes you are in full control over how many options you would like to add to the schemes.

The options within an issue security scheme are known as Security Levels. They represent the levels of security that users need to meet before JIRA will allow them access to the requested issue. Please note that even though they are called security levels, this does not mean there are any forms of hierarchy amongst the set of levels you create.

To configure an issue security scheme:

  1. Browse to the Issue Security Schemes page.
  2. Click on the Security Levels link for the issue security scheme you wish to configure. This will bring up the Edit Issue Security Levels page.

From here, you can create new security levels and assign users to existing security levels.

Adding a security level

Since issue security schemes do not define any security levels, the first step to configure your scheme would be to create a set of new security levels.

  1. Browse to the Edit Issue Security Levels page for the issue security scheme you wish to configure.
  2. Provide a meaningful name for the new security level in the Add Security Level section.
  3. Provide an optional description.
  4. Click on the Add Security Level button.

You can add as many security levels as you like in a scheme. A good practice is to design your security levels based on your team or project roles.

Assigning users to a security level

Similar to permission schemes, once you have your security levels in place, you will then need to assign users to each of the levels. Users assigned to the security level will have permission to view issues with the specified security level.

  1. Browse to the Edit Issue Security Levels page.
  2. Click on the Add link for the security level you wish to assign users to. This will bring up the Add User/Group/Project Role to Issue Security Level page.
  3. Select the users you wish to assign to the security level.
  4. Click on the Add button to assign the users.

While it may be tempting to use the Single User option to add individual users, it is a better practice to use other options such as Project Role and Group as this is more flexible by not tying the permission to individual users and allows you to control permission with options such as group association.

Setting a default security level

You can set a security level to be the default option for issues if none is selected. This can be a useful feature for projects with high security requirements to prevent users (with Set Issue Security permission) from forgetting to assign a security level for their issues.

  1. Browse to the Edit Issue Security Levels page.
  2. Click on the Default link for the security level you wish to set as default.

Once set as default, the security level will have Default next to its name. Now, when the user creates an issue and does not assign a security level, the default security level will be applied.

Deleting a security level

You can revoke users assigned to security levels or remove the security level completely. When you revoke a user, he/she will no longer have access to the issue unless there is another user setting which the user also belongs to, applied to the same security level.

To revoke a user from a security level:

  1. Browse to the Edit Issue Security Levels page.
  2. Click on the Delete link for the Users/Groups/Project Roles you wish to remove. This will take you to the Delete Issue Security page.
  3. Click on the Delete button to revoke the user.

When you delete a security level, you will be affecting all the issues that are currently set to that security level. JIRA allows you to update those issues to use a different security level (if one is available), or have no security level applied.

  1. Browse to the Edit Issue Security Levels page.
  2. Click on the Delete link for the security level you wish to remove. This will take you to the Delete Issue Security Level page. If there are issues set to the security level, JIRA will list the issues and also ask you to change their security level settings.
  3. Select a new security level for the issues affected.
  4. Click on the Delete button to remove the security level.

Applying an issue security scheme

Just like permission schemes, the project administrators apply issue security schemes to projects. Applying an issue security scheme is similar to when you apply a workflow scheme, there is an intermediate migration step involved. This is to ensure existing issues with issue security levels set can be successfully migrated over to the new security levels in the scheme.

  1. Log into JIRA as a project administrator.
  2. Select the project(s) that will be using the issue security scheme.
  3. Click on the Select link for Issue Security Scheme. This will bring up the Associate Issue Security Scheme to Project page.
  4. Select the permission scheme to use.
  5. Click on the Next button to move to step 2 of the process.
  6. Select the new security level to apply to the existing issue that might be affected by this change.
  7. Click on the Associate button to apply the new issue security scheme.

Securing your JIRA 4

Workflow security

Security features that we have looked at up until now are not applied to workflows. When securing JIRA, you will also need to consider who will be allowed to perform certain workflow transitions. For example, only users in the managers group will be able to execute the Authorize transition on issues. For you to enforce security on workflows, you will have to set it on each of the transitions you have, by adding workflow conditions.

Help Desk Project

JIRA can be configured to capture data with customized screens and fields, and process the captured data through workflows. What we need to do now is to secure the data we have gathered to make sure only the authorized users can access and manipulate issues.

Since our Help Desk Project is used by our internal team, what we really need to do is to secure our issues to ensure the data they hold do not get modified by other users, usually by mistake. This allows us to mitigate human errors by handling access accordingly.

To achieve this, we have the following requirements:

  • We need to be able to tell who belongs to the help desk team.
  • Restrict issue assign operation to only the user who has submitted the ticket and members of the help desk team.
  • Not to allow tickets to be moved to other projects.
  • Limit the assignee of tickets to the reporter and members of the help desk team.

Of course, there are a lot of other permissions we can apply here. The above four requirements will be a good starting point for us to build on further.

Setting up groups

The first thing we need to do is to set up a new group for our help desk team members, this will help us distinguish normal JIRA users from our help desk staff.

  1. Browse to the Group Browser page.
  2. Name the new group help-desk-team in the Add Group section.
  3. Click on the Add Group button.

We can create more groups for other teams and departments, for our scenario here, since anyone can log a ticket in our project, there is no need to make that distinction.

Setting up user group association

With our group setup, we can start assigning members of our team to the new group.

  1. Browse to the Group Browser page.
  2. Click on the Edit Members link for the support-desk-team group.
  3. Select users with the user picker or simply type in the usernames separated by a comma. This time, let's add our admin user to the group.
  4. Click on the Join button.

Setting up a permission scheme

The next step is to set up permissions for our Help Desk project, so we need to have our own permission scheme. As always, it is more efficient to copy the Default Permission Scheme as a base and make our modifications on top, since we are only making a few changes here.

  1. Browse to the Permission Schemes pages.
  2. Click on the Copy link for Default Permission Scheme.
  3. Click on the Edit link for the new Copy of Default Permission Scheme created.
  4. Name the new permission scheme Help Desk Permission Scheme.
  5. Change the description to Permission scheme designed for Help Desk team projects.

Now we have our base permission scheme set up, we can start on the fun part: interpreting requirements and implementing them in JIRA.

Setting up permissions

The first thing we need to do when we start setting up permissions is to try to match up existing JIRA permissions to our requirements. In our case, we want to restrict the following:

  • Who can assign issues
  • Who can be assigned to an issue
  • To disable issues from being moved

Looking at the existing list of JIRA permissions, we can see that we can match up the requirements with the Assign Issues, Assignable Users, and Move Issues permissions, respectively.

Once we have worked out what permissions we need to modify, the next step is to work out a strategy to specify which users that should be given the permissions. Restricting Move Issue options is simple. All we have to do is remove the permission from everyone, thus effectively preventing anyone from moving issues in our project.

The next two requirements are similar, as they are both granted to the reporter (user that submitted the ticket), and our new help-desk-team group.

  1. Browse to the Permission Schemes pages.
  2. Click on the Permissions link for Help Desk Permission Scheme.
  3. Click on the Grant permission link.
  4. Select both Assign Users and Assignable Users permissions.
  5. Select the Reporter option.
  6. Click on the Add button.
  7. Repeat the steps and grant the help-desk-team group both permissions.

By selecting both permissions in one go, we have quickly granted multiple permissions to users. Now we need to remove all the users granted with the Move Issues permission. There should be only one granted at the moment, Project Role (Developer), but if you have more than one granted, you will need to remove all of them.

  1. Browse to the Permission Schemes pages.
  2. Click on the Permissions link for Help Desk Permission Scheme.
  3. Click on the Delete link for all the users that have been granted Move Issues permission.

And that's it! We have addressed all of our permission requirements with just a few clicks.

Putting it together

Last but not least, we can now put on our project administrator's hat and apply our new permission scheme to our Help Desk project.

  1. Browse to the Project Administration page for our Help Desk project.
  2. Click on the Select link for Permission Scheme.
  3. Select Help Desk Permission Scheme.
  4. Click on the Associate button.

By associating the permission scheme with our project, we have applied all of our permission changes. Now if we create a new issue or edit an existing issue, you will notice that the list of assignees will no longer include all users in JIRA.

Summary

In this article, we covered JIRA's user management options with groups and project roles. While both are very similar, groups are global while project roles are specific to each project.

We have also learned in detail how JIRA hierarchically manages permissions at each permission level and how one can manage them.


Further resources on this subject:


About the Author :


Patrick Li

Patrick Li is the cofounder and senior engineer of AppFusions. AppFusions is the leading Atlassian partner specializing in integration solutions with many enterprise applications and platforms, including IBM Connections, Jive, Google Apps, Box, SugarCRM, and more.

He has worked in the Atlassian ecosystem for over five years, developing products and solutions for Atlassian platform and providing expert consulting services. He is one of the top contributors to the Atlassian community, providing answers and suggestions on the Atlassian user forum.

He is extensively experienced in designing and deploying Atlassian solutions from the ground up, and customizing existing deployments for clients across verticals such as Healthcare, Software Engineering, Financial Services, and Government Agencies.

Books From Packt


Firebug 1.5: Editing, Debugging, and Monitoring Web Pages
Firebug 1.5: Editing, Debugging, and Monitoring Web Pages

Java EE 6 with GlassFish 3 Application Server
Java EE 6 with GlassFish 3 Application Server

Oracle Identity and Access Manager 11g for Administrators: RAW
Oracle Identity and Access Manager 11g for Administrators: RAW

Managing Software Development with Trac and Subversion
Managing Software Development with Trac and Subversion

Least Privilege Security for Windows 7, Vista and XP
Least Privilege Security for Windows 7, Vista and XP

Tomcat 6 Developer's Guide
Tomcat 6 Developer's Guide

MySQL Admin Cookbook
MySQL Admin Cookbook

Microsoft SQL Azure Enterprise Application Development
Microsoft SQL Azure Enterprise Application Development


No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
8
n
c
X
n
U
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software