How to Improve Jira Service Desk Security: the Complete 2020 Starter's Guide

ManooshUncategorizedLeave a Comment

secure jira service desk

This article was written by Guillaume Lorquet, an Atlassian Engineer at iDalko

Jira Service Desk is mainly considered as a customer portal. It is also well-known among its users for the features it offers like automation, customer feedback, SLA’s, and queues. It gives more user-friendly access to your customers and provides them with a way to submit their requests to your support team. It also helps them communicate in an easier and more efficient way by allowing them to add information via comment or attachment, following their tickets’ status, and sharing it with other users. But, how can we improve our Jira service desk security and management to make good use of its features and functions?

In this article, we’ll first go over Jira service desk’s native functionalities to learn how we can manage our service desk by customizing its access for different teams. Then we’ll introduce 2 apps with which we can secure our Jira service desk and make the best use of it. We’ll also discuss how to secure your Service Desk using higher-level technical configurations. For instance, when Jira is only accessible from an internal network or when it is hidden behind other security tools.

Manage your Jira Service Desk Security with the Native Functionalities

Even if the marketplace proposes a variety of apps, it’s always a good idea to know the tools’ native functionalities first. This would enable you to use them to their full potential and to improve the functionalities by making use of the apps afterward.

To secure your platform, you need to clarify how you want to manage it in a way that meets all your teams’ criteria. So you should first ask yourself who can access your Jira Service Desk.

Well, there are three options:

  1. Anyone can access your Jira service desk and even create an account.
  2. Anyone who has an account on your platform can access the portal.
  3. Depending on the support, you want to be more accurate and select who can access a specific part of the portal.

Let’s explain it with a simple example. Imagine you have multiple projects with different teams like IT support, HR, marketing, and so on. You can easily provide the necessary access to Jira service desk for each of these teams. This is how you might want to customize it:

manage jira service desk

So the table indicates that the people who only have a Jira account and are not authorized cannot access your human resources projects via your Jira service desk.

The Public Signup Functionality

The Public signup functionality lets the users create their own accounts. If you don’t want to manage your customers’ accounts or you want to use Email requests, then you can use this functionality. However, enabling this option is probably not the best idea if you want to keep your users’ access under control and improve your Service Desk security.

Even if a customer doesn’t pay for a license, a Jira user is created whenever someone creates an account. So you might want to be careful with projects associated with the permission User who has a Jira account, now that they have a Jira account and can access the projects with this permission level. This option should be used only if you approve of such access or if you want to use Email requests.

jira service desk public signup

Keeping Everything under Control in your Jira Service Desk

If you want to keep the situation under control, I suggest you disable the Public signup functionality and use one of these customer permissions instead:

  1. Customers who have an account: any user can raise a ticket in projects that use this type of permission.
  2. Customers who are added to a project: any user who’s added as a customer in a project, will be able to create a ticket.

If we go back to our previous example with the Support team, Marketing, and Human Resources, we know that the HR team only wants the authorized people added to the project.

Here you see how a user can view the service desk. If you’re an internal user and you have been added to an HR project, you’ll end up on the red screen on the left. And if you a user with an account but you haven’t been added to an HR project, then you’ll see the blue screen on the right.

Both users can access the projects which are accessible by a Jira account, but they cannot access the projects that require a higher permission level. jira service desk accessibility for different teams

As you probably don’t want to add customers one by one, there’s also the possibility to manage them by creating groups. Associate customers with one or multiple groups and add these groups to the Service Desk Customers project roles. All users added to this group will be automatically considered as a customer for the relevant project.

In our example, we could create a group “jira-servicedesk-customers-hr” to manage it.

creating groups in jira service desk

All the users in the group “jira-servicedesk-customers-hr” are now associated, as a customer, with the project “Human Resources”.

groups in jira service desk

Improve your Jira Service Desk Security with apps

There are a lot of apps on the Marketplace that you can use to improve the portal. Here we introduce a couple of apps that can help you improve your Jira service desk security:

Refined Theme for Jira Cloud and Server/ Data Center

If you want to customize your portal through personalized site and structure, then the app, Refined Theme for Jira Cloud and Server/ Data Center is for you. It’s especially useful when you deal with many support teams and you want to manage them regarding the main subjects as the IT department. These subjects can be technical support, software support, security team, and so on.

In this example, we have a site “Help Center” with these 2 categories:

  1. Internal support: Permissions are associated to make it visible only for the internal teams.
  2. IT support: No permissions are associated.
    help center

With a customized design, your home page proposes these 2 categories visible by the customer depending on the permissions:

  1. Customers with permission to raise a request to internal support.
    customize your service desk with permissions
  2. Customers without the permission to raise a request to internal support.
    service desk customization with permissions

When you select this category, a link will pop up which will redirect you to the right page. If you click on the “IT support”, then you can choose between technical or software support or the security team. You can also type in your keyword and look it up using the search bar. example service desk permission customization

Extension for Jira Service Desk

But you might want more and would like to hide some requests for specific users. Then you have the option to use the Extension for Jira Service Desk app. It proposes a variety of functionalities to :

  • customize the visibility of your portal to a specific group, in case you don’t want to use the native functionality.
  • select which request type(s) you want to show to which customers.

If you want to go further, you can also customize the field visibility, etc.

This is how we associate permissions with customers’ request type:

  1. As an administrator, I can see all request types.
    admins' jira service desk security
  2. As an employee, I can’t see all request types.
    jira service desk security for employees

Conclusion

Even with the help of its native functionalities, you can guarantee Jira Service Desk security with its permission and user management. Use group management and match it with the project roles and it’ll be a piece of cake. The apps introduced in this article can also help you improve your basis with a more accurate structure or customize it in the best way allowed by the permissions.

If you’re interested in a comparison between Jira service desk and Helpdesk for Jira, check out this blog post. And find out more here if you want to learn about the deployment models for your Atlassian stack.

Leave a Reply

Your email address will not be published. Required fields are marked *