Jira Service Management

Jira Service Management (Service Desk) enables to receive, track, manage, and resolve requests from customers. Use to fetch assets from the Jira Insight platform. This is intended to be used with Jira Service Management.

Asset Types Fetched

• Devices, Users, Business Applications, Tickets, Application Services, Networks, Certificates, Software

Before You Begin

To correlate data correctly in Axonius, define the following fields in your system as follows:

APIs

Axonius uses the Get AQL Objects API.

Minimum Scope Sets

To fetch all asset types, the following minimum scope sets are required:

read:issue:jira
read:field:jira
read:user:jira
read:attachment:jira
read:cmdb-object:jira
read:cmdb-schema:jira

To fetch assets AND use Enforcement Actions, the following minimum scope sets are required:

read:issue:jira
read:field:jira
read:project:jira
read:issue-type:jira
read:user:jira
read:attachment:jira
read:cmdb-object:jira
read:cmdb-schema:jira
write:issue:jira
write:attachment:jira
delete:attachment:jira
write:cmdb-object:jira
delete:cmdb-object:jira

Supported From Version

Supported from Axonius version 4.5

Connecting the Adapter in Axonius

Using Scoped Credentials

The Jira Service Management adapter detects and supports four credential modes based on the field values provided. The credential mode is determined automatically - no need to configure any additional settings in the adapter's Add Connection screen.

The credential mode is auto-detected based on the following decision tree (evaluated top-to-bottom):

📘

Notes

• Mode 1 is for on-prem/server installations.
• Modes 2, 3, and 4 use granular scoped credentials and require specific OAuth scopes - classic scopes such as read:jira-work or write:jira-work are not sufficient. The OAuth app or service account must be granted the specific granular scopes listed in the relevant minimum scope set.
• Mode 5 uses classic API tokens where scopes are not applicable.

Prerequisites

• The scoped API base URL is (https://api.atlassian.com/ex/jira/<cloudId>/rest/...
• "Fetch Comments" does not require the read:comment:jira permission - comments are explicitly excluded from API responses by the adapter (fields: ["*all", "-comment"]).
• The Jira Service Management - Update Tickets Enforcement Action requires the delete:attachment:jira scope when an existing CSV attachment is present. This scope is easy to miss during the permission setup, so make sure you include it.

How to configure each mode in the Axonius interface

Each credential mode requires different values for the Axonius fields when connecting the adapter:

Mode 2: OAuth 2.0 Client Credentials (Service Account)

• The adapter will automatically fetch a Bearer token from https://auth.atlassian.com/oauth/token.
• Token has a 1-hour TTL and is refreshed automatically.

Mode 3: Service Account Scoped API Token

Mode 4: Scoped API Token (Pre-configured URL)

Mode 5: Classic API Token (Default Behavior)

Scoped API Routing

When using scoped credentials (modes 2, 3, or 4), all Jira REST API calls are automatically routed through Atlassian's unified cloud endpoint:

• Standard (classic): https://<site>.atlassian.net/rest/<api_suffix>
• Scoped: https://api.atlassian.com/ex/jira/<cloudId>/rest/<api_suffix>

📘

Note

The Cloud ID is auto-discovered when using modes 2 or 3 - you don't need to supply it manually. The adapter retrieves it from https://your-domain.atlassian.net/_edge/tenant_info. If you prefer to specify the Cloud ID manually, you can set the Domain field to the scoped API gateway URL format (mode 4).

Connection Parameters - Axonius Interface

Required Parameters

1. Host Name or IP Address, User Name and API Token - See Using Scoped Credentials for information on the different authentication methods and the values required for each of these fields.

   📘

   Note

   The API Token is not the same as the Admin Key. For information on how to create an API Token, see Manage API tokens for your Atlassian account.

2. Verify SSL - Select whether to verify the SSL certificate offered by the value supplied in Host Name or IP Address. For more details, see SSL Trust & CA Settings.

Optional Parameters

1. Jira Service Management API version - The version type. The default value is 1.0
2. HTTPS Proxy - A proxy to use when connecting to the value supplied in Host Name or IP Address.
3. HTTPS Proxy User Name - The user name to use when connecting to the value supplied in Host Name or IP Address via the value supplied in HTTPS Proxy.
4. HTTPS Proxy Password - The password to use when connecting to the value supplied in Host Name or IP Address via the value supplied in HTTPS Proxy.
5. Use Cloud API - Use this option to add support for cloud-based installations of Jira Service Management (Service Desk) with Jira Insight.
6. Workspace IDs - Enter an optional list of Workspace IDs to use. If no Workspace IDs are entered, the adapter queries the configured hosts for all Workspace IDs.

To learn more about common adapter connection parameters and buttons, see Adding a New Adapter Connection.

Jira Service Management Settings for Cloud

Jira Service Management Settings for On Prem

Advanced Settings

📘

Note

Advanced settings can either apply to all connections for this adapter, or to a specific connection. Refer to ​Advanced Configuration for Adapters.

1. IQL query (Override Filter Device object types) - Enter a custom IQL query so that all objects will be treated as devices. Note that using this setting will override the configuration value set in Filter Device object types.
2. Filter Device object types - Enter a comma-separated list of objects that the client wants to fetch, for example 'Servers, laptops, desktops'. Then only these object types are fetched.

📘

Note

If you do not define the object types using this setting, then ALL assets, regardless of type, are mapped as devices.

3. IQL query for Users (Override Filter Users object types) - Enter a custom IQL query so that all objects will be treated as users. Note that using this setting will override the configuration value set in Filter Users object types.

4. Filter Users object types - Enter a comma-separated list of objects to parse as users, for example: ‘Employees’.

5. IQL query to asset mapping - From the Axonius Asset Type dropdown, select an asset type. In the IQL query for Jira field, map a relevant IQL query to fetch the selected asset from Jira. Click + to add more assets to fetch.

6. Use asset name for hostname - Select this option to use the asset name for the hostname if the hostname doesn't exist.

7. Use Device 'Updated' as 'Last Seen' - Select this option to use the "Updated" field as "Last Seen".

8. Additional MAC Address Field Names - Enter a list of Jira field names that the adapter should recognize as MAC address fields. To add each field name, type the value and then press Enter to create a new entry.

9. Additional IP Address Field Names - Enter a list of Jira field names that the adapter should recognize as IP address fields. To add each field name, type the value and then press Enter to create a new entry.

10. Custom schema entry (JSON) (Custom devices schema, Custom users schema) - Use these settings to add a JSON file to fetch information from one object to another. Refer to Using Custom Schema Entries to add a JSON file to Fetch Information from One Object to Another for details of how to configure these fields.

11. Custom Parsing

12. Fetch EC Action ticket updates - Select this option to configure the adapter to fetch updates on Jira Service Management tickets created using the Jira Service Management - Create Issue or Jira Service Management - Create Issue per Asset enforcement actions.

    The updated ticket information is stored in Axonius and can be displayed in the Tickets table of each relevant asset (user, device).

13. Exclude devices with the following statuses - Enter a comma-separated list of statuses. Devices with one of these statuses will not be ingested into the system.

📘

Note

To learn more about Adapter Configuration tab advanced settings, see Adapter Advanced Settings.

Object Names Object names in Axonius are set according to the following parameters:

• The naming attribute in Jira. This is the attribute of the Jira object set as a label attribute (could be an attribute called 'green').

or

• The 'Name' attribute in the Jira object

or

• The 'objectKey' of the Jira object

in this order.

Using Custom Schema Entries to Add a JSON File to Fetch Information from One Object to Another

You can use Custom devices schema and Custom users schema to add a JSON file to fetch information from one object to another. For instance from a source. For instance to enrich a laptop with information from another object. You can add more than one JSON file. The JSON file must be of the format:

{
        “type”: “link”,
        “link_type”: “reference”,
        “source_table”: “Manufacturer”,
        “source_field”: “Software”,
        “destination_table”: “Software”,
        “linked_record_identifier”: “objectKey”,
        “destination_table_fields”: [“Type”, “Vendor”],
        “destination_table_query”: “objectTypeId=5"
}

• link_type - The only supported type is reference.
• source_table - The type of the source object type in Jira. This is the table that will be enriched from the data in the destination_table.
• source_field - The attribute of the object type from which the values should be brought. Enrich the contents of the source_table, which has the same name as the value of the source_field in the destination_table, with the contents of the destination_table field.
• destination_table - The destination object type in Jira from which the data will be imported.
• linked_record_identifier - the cname of the attribute that identifies the object.

All of the above are mandatory.

• destination table fields (optional) - List of fields to bring from the source - if no fields are listed, then all fields are brought.
• destination_table_query (optional) - IQL Jira query to run when searching for the destination object.

It is not necessary to list all of the source tables, instead of listing all source_tables, it is possible to write “$ROOT” in the “source_table” field.

“type”: “link”,
    “link_type”: “reference”,
    “source_table”: “$ROOT”,
    “source_field”: “Owner”,
    “destination_table”: “User”

For instance, if the source table contains the field "owner" then the system fetches the object of the sort "user" for all of the tables. This will populate associated users for all source objects that have the field "owner".

Version Matrix

This adapter was only tested with the versions marked as supported, but may work with other versions. Contact Axonius Support if you have a version that is not listed, which is not functioning as expected.

Related Enforcement Actions

• Jira Service Management - Create Ticket
• Jira Service Management - Create Ticket per Asset
• Jira Service Management - Update Tickets
• Jira Service Management - Create Insight Asset per Asset
• Jira Service Management - Update Insight Asset
• Jira Service Management - Remove Insight Asset