Atlassian JIRA Configuration Tutorial: Overview of JIRA Security

Part I - JIRA Schemes (Part 1)

Part II - Overview of JIRA Security

Part III - JIRA Schemes (Part 2)

Part IV - JIRA Schemes (Part 3)

JIRA flexibility is notorious and its security features are no exception. This blog post is an overview of JIRA security features and how to configure permissions to secure JIRA, your projects and all of your issues.

Users, Groups and Project Roles

At the global level, JIRA organizes users into groups and project roles. Groups are named sets of users and project roles are named sets of users and groups:

The administrator can create, edit an delete any number of users, groups and project roles.

Although, at first, the existence of both groups and project roles might seem redundant, project roles are important since they provide an additional level of indirection to decouple permissions from user accounts in a project. JIRA permissions at the global level (Global Permissions) can only be granted to groups. JIRA permissions at the project level can be granted at any combination of users, groups and project roles. An effective organization of your users (and groups) into project roles will help you create and maintain clean security policies in your project by:

• Defining the project roles you need.
• Assigning permissions to your project roles in a permission scheme.
• Assign a permission scheme to a project.

At the global level, to ease administration of a great number of projects, JIRA lets you define a project role's default members.

Global JIRA Permissions

Global JIRA permissions are (as of JIRA 4.2):

• JIRA System Administrators.
• JIRA Administrators.
• JIRA Users.
• Browse Users.
• Create Shared Objects.
• Manage Group Filter Subscriptions.
• Bulk Change.

Most of them are self-explanatory and further information about each of them can be found in the official JIRA documentation.

JIRA Users

This permission is required for users to be able to log in into JIRA. By default, groups that are granted this permissions will be assigned to any newly created user.

Disabling a User

Revoking this permission to a user, that is removing the users from every group that is granted the JIRA Users permission, will effectively disable the user and it won't count against your JIRA license limit.

Project Permissions

Project permissions are defined by JIRA and can be granted to an identity in a permission scheme. Assigning a permission scheme to a project will make those permissions effective in that project context.

Examples of most commonly used permissions are:

• Administer project
• Browse project
• Create issue
• Edit issue
• Resolve issue
• Close issue
• Add comment
• Delete comment
• Work on issues

For the complete list of permissions for a given JIRA version please check JIRA documentation or navigate to the Edit Permissions window of your JIRA installation accessible at the following URL:

http://your.jira/secure/admin/EditPermissions!default.jspa?schemeId=0

Further information about assigning project permissions to users, please check out this blog post.

Securing Workflow Transitions

The permissions seen so far make no mention of workflows and workflow transitions. Obviously, workflows are a fundamental part of JIRA functionality and it's essential for an administrator to be able to establish security policies at the workflow transition level.

Permission requirements can be associated to workflow transition using Conditions.

Conditions

Conditions essentially are validation rules that must be satisfied for a workflow transition to be executed. JIRA ships many built in conditions and many of them can be used to establish fine tuned security policies at a workflow transition level. The available security-related workflow transition conditions are (as of JIRA 4.2):

• Only assignee.
• Only reporter.
• Permission.
• User in group.
• User in group custom field.
• User in project role.

These conditions can be used to build security policies using any kind of identity seen so far: group and project role. Moreover, other identities related to a specific issue are available such as assignee and reporter.

Conditions are basic JIRA-provided parametrizable propositions that can be used to build more complex statements using the JIRA administration console.

Validators

Validators are similar to conditions with the difference that validators are executed against input parameters. As far as it concerns security policies, conditions is the way to go. Anyway, a Permission validator is available to check if the current user has a specific permission.

Securing Issues in a Project

We've seen many ways an administrator can secure its JIRA installation so far: at the global level, at the project level and at the workflow transaction level. There's case we haven't considered yet, though: applying distinct security policies to issues inside a project.

To achieve this goal in a flexible way, JIRA provides the ability to categorize a project's issues in the so-called security levels. A security level is an attribute of an issue that can be set in the usual ways:

• By using a screen that configured to edit such a field.
• By a workflow transaction.

An issue in a security level can be accessed only by identities (users, groups or project roles) that are granted permissions. The link between a security level and the identities that are granted access is established by means of an issue security scheme.

As usual, as soon as a project is associated to a security scheme, the scheme security policies are enforced. You can now create as many security level as your project needs and grant permissions to the corresponding users for every security level.

The available identities to grant permissions to in a security level are:

• Reporter.
• Group.
• Single User.
• Project Lead.
• Assignee.
• User custom field value.
• Project role.
• Group custom field value.

Next Steps

In this blog post we've introduced the facilities that JIRA provides to secure the operations it offers and the object it manages with flexible security policies.

In the next part of this series we'll examine what JIRA schemes are and how they can be used to decouple configurations from the context in which they are applied.