Integrating Okta with Jira Service Management (Hint: It’s All in the Assets)

[#1]

Identity management requests are among the most frequent tasks in IT Service Management. Every day, support teams handle user access changes be it from onboarding new employees to updating group memberships because of an organization change. It's all managed through service desk tickets that require careful review and approval. Integrating an identity provider like Okta with Jira Service Management (JSM) can reduce the processing time for these type of tickets. In this blog, we’ll explore common identity-related ITSM use cases, see how Assets help meet these needs, walk through how to synchronize Okta data into Assets (using the OnLink).

Common ITSM Use Cases Involving Okta

Its not uncommon for IT support teams faced with a high volume of access and account-related requests. These routine tasks are crucial for security and productivity, yet they consume substantial support effort when handled manually. Some of the most common ITSM tickets related to Okta include:

• Adding a user to a group: Granting additional access or permissions by adding an employee to an Okta group (e.g. giving access to a software application).
  
  
• Removing a user from a group: Revoking access by removing group membership when it’s no longer needed.
  
  
• Adding a role to a user: Assigning a new role or application license to a user (for example, promoting a user’s admin privileges for a tool).
  
  
• Removing a role from a user: Downgrading or removing privileges/roles from a user’s account when appropriate.
  
  
• Provisioning a new user: Creating accounts and initial group memberships for onboarding a new hire.
  
  
• De-provisioning a user: Disabling or removing accounts and access for a departing employee (offboarding).
  
  

Each of these requests typically goes through JSM as a ticket, often with approvals and manual steps by IT staff. Automating such use cases frees up support teams to focus on high-value tasks.

How Assets in JSM Helps with Identity Management

Imagine Assets is pre-populated with users, roles, groups, devices from Okta.

You might wonder why is this valuable? Please allow me to explain.
 When an ticket is opened (e.g, “Add this user to the Marketing Okta group”), the support agent can quickly look up the current roles, group memberships, and other attributes of that user in Assets without switching to the Okta admin console. Having the employee’s profile, role assignments, group memberships, and even device information readily available in JSM speeds up triage and resolution. IT teams can validate access rights on the fly and ensure compliance with corporate policies.

In summary, Assets to the rescue: by syncing identity data from Okta into Assets, JSM becomes a one-stop hub for user information. This integration enables automated checks and smarter workflows (for example, auto-approving requests that meet certain criteria), cuts down manual effort, and improves service response times . It enhances security too, ensuring that any changes are made based on up-to-date data about the user’s current access . The support desk can confidently address identity-related tickets with full context, leading to quicker and more accurate resolutions.

Importing and Synchronizing Okta Information into Assets

Now, let’s discuss how to get your Okta identity data into JSM’s Assets and keep it in sync. OnLink make this integration straightforward by automating data import from Okta to Assets. Below is a step-by-step guide to configure the Okta–JSM Assets connection and set up automated synchronization of users, groups, roles, and devices.

1. Configuring the Okta Connection

Before importing data, you need to establish a connection between JSM and Okta:

• Okta Domain: Identify your Okta organization’s domain (for example, yourcompany.okta.com). You can find this in your Okta Admin Console (it’s usually visible in the URL or under your account name). This will serve as the endpoint URL that OnLink uses to call Okta APIs. (Refer to Okta documentation if needed for finding your exact domain URL).
  
  
• Okta API Token: Generate an API token from your Okta admin settings, which will allow OnLink to read data from Okta. In Okta, an administrator can create a token by navigating to Security > API > Tokens and clicking “Create Token.” Give it a name (e.g. “JSM Integration”) and copy the token value. This token is used by OnLink to authenticate with Okta’s API. (For detailed steps, see Okta’s guide on creating API tokens.)  Ensure you keep the token secure, as it grants access according to your admin permissions.
  
  

2. Setting Up an Assets Import

Next, configure Assets to receive data from Okta:

1. Choose your Assets schema: In Jira Service Management, open Assets (the Assets menu in your project) and navigate to the schema where you want to import Okta data. For example, you might have a schema called “Okta IDM” Within that schema, determine the object types you’ll use for Users, Groups, Roles, Devices, etc.
   
   
2. Create a new import configuration: Still in the Assets schema configuration, go to Import → click Create Import, and select OnLink Importer as the import type. Give the import a name (e.g. “Okta User Sync”) and create it. This sets up a pipeline for Assets to receive data via OnLink.

3. Mapping Okta User Fields to Asset Attributes

In the OnLink configuration interface, you’ll set up field mappings that tell OnLink how to translate Okta’s user data into Assets object attributes. OnLink will have already detected which Assets schema and object type you intend to import into – make sure it’s pointing to your “User” object type (or equivalent) in Assets.

Now, define the mappings. Each mapping is a simple line that maps a field from Okta to an attribute in Assets. For example, a basic user profile mapping might look like this:

key:id=WorkerID

map:profile.email=User

map:profile.firstName=First Name

map:profile.lastName=Last Name

map:profile.managerId=Manager UserID

map:profile.manager=Manager Name

map:profile.department=Department

Let’s break down what this means:

• key:id=WorkerID – This line designates the unique identifier for each object. Here we use the Okta user’s id as the unique key, mapping it to the “WorkerID” attribute in Assets. The key: prefix tells OnLink which field to use to uniquely identify and update user objects. Using a stable unique ID ensures that if a user’s data changes, the existing record in Assets is updated rather than creating duplicates .
  
  
• map:profile.email=User – Maps the Okta user’s email address to an attribute called “User” in Assets. Often, “User” might be an attribute of type User (linking to the JSM user account). In essence, this populates the user’s email/username in the Assets record .
  
  
• map:profile.firstName=First Name – Maps the Okta profile’s firstName field to the “First Name” attribute in Assets.
  
  
• map:profile.lastName=Last Name – Similarly maps the last name.
  
  
• map:profile.managerId=Manager UserID – Maps the manager’s Okta user ID to an attribute (perhaps to link to another Assets object for the manager).
  
  
• map:profile.manager=Manager Name – Maps the manager’s name (Okta stores the manager’s name in the profile if configured) to a “Manager Name” attribute.
  
  

map:profile.department=Department – Maps the department field from Okta to a Department attribute in Assets (which might be a reference to a Department object or simply a text field for department name).

4. Importing User Roles, Groups, and Apps

In Okta, each user can belong to multiple groups, have various roles, and be assigned to applications. It’s incredibly useful for the service desk to see these access entitlements in JSM Assets as part of the user’s record. With OnLink, you can pull those lists in as well.

Okta’s API provides arrays for a user’s groups, roles, and apps. We can map those arrays into Assets by leveraging Assets object references. Suppose you have separate object types in Assets for Roles, Groups, and Apps (with attributes like “Name” to identify each). You can configure the mapping to populate those relationships as follows:

key:id=Username

map:profile.firstName=Firstname

map:profile.lastName=Lastname

map:roles=Roles|Name=${roles}

map:groups=Groups|Name=${groups}

map:apps=Apps|Name=${apps}

config:section=roles,groups,apps

Here’s what this does:

• We still use key:id=Username (maybe using the Okta username or id as a key for the user object in this context – ensure consistency with the prior user import; often the Okta id or login can serve as key). We map first and last name again just as identifiers (these could be redundant if done above, but including them doesn’t hurt).
  
  
• The important lines are:
  
  
  • map:roles=Roles|Name=${roles} – This tells OnLink to take the list of roles from Okta (roles array) and map them to the Assets attribute Roles. The syntax Roles|Name=${roles} means: for each role in the incoming data, find or create a Roles object in Assets where the Name attribute equals that role. Then link the user to that Roles object. Essentially, it loads the role names into the user’s Roles field by referencing the Role objects (by Name) .
    
    
  • map:groups=Groups|Name=${groups} – Similarly, map each Okta group in the user’s membership list to an Assets Groups object by Name. After import, the user object in Assets will have links to all Group objects corresponding to their Okta groups .
    
    
  • map:apps=Apps|Name=${apps} – Likewise for applications assigned to the user, mapping to an Apps object in Assets by Name. This could represent all the Okta-managed applications the user has access to.
    
    
• The line config:section=roles,groups,apps is crucial – it instructs OnLink to fetch those related lists from Okta. This uses Okta’s capability to expand the user data to include roles, groups, and apps in one go. In practice, OnLink will call the Okta Users API with a query to include those sections, so it receives the user’s role names, group names, and app names along with the profile. This mapping then parses those into the respective Assets objects.
  
  

 Syncing Detailed Group and Application Objects (Optional)

The previous step linked users to group and app objects by name, but you might also want to import additional details about each Group or Application from Okta. OnLink allows you to pull data from any Okta API endpoint by adjusting the configuration. We can set up separate imports (or additional mapping sections) for Okta’s Groups API and Apps API to populate the Assets Group and App object types more fully.

For example, to import all Okta groups into Assets (object type “Group”), you could use a configuration like:

Groups:

key:id=Group ID

map:profile.name=Group Name

map:profile.description=Group Desc

config:data_source=/api/v1/groups

And for Okta applications (object type “App”):

Apps:

key:id=App ID

map:label=App Name

config:data_source=/api/v1/apps

In these snippets, we use config:data_source= to specify a different Okta API endpoint. By default, OnLink was calling the /api/v1/users endpoint for user data . By pointing to /api/v1/groups, we tell it to retrieve all groups. We map the group id to a unique “Group ID” in Assets, and map the group’s name and description to attributes in the Group object (like “Group Name” and “Group Desc”). Similarly for apps, using the app id and label (application name).

6. Importing Device Information from Okta

Aside from users and groups, Okta can also store information about devices (if you use Okta’s device management or endpoint identity features). For instance, Okta’s Devices API can list devices (like enrolled laptops or phones) and link them to users. Integrating device data into JSM Assets can be extremely useful for service desk tasks (as one of the most frequent IT requests involves hardware issues ).

Using OnLink, you can retrieve device records from Okta much like we did for users. Okta’s devices endpoint requires a slightly different call – here’s an example mapping configuration for devices:

Devices:

key:id=DeviceID

map:profile.displayName=Device Name

map:profile.platform=Device Platform

map:profile.manufacturer=Device Manufacturer

map:profile.model=Device Model

map:profile.osVersion=Device OS Version

map:_embedded.users.0.user.profile.firstName=First Name

map:_embedded.users.0.user.profile.lastName=Last Name

map:_embedded.users.0.user.profile.email=Email

config:data_source=/api/v1/devices?limit=200&expand=userSummary

Breaking this down:

• config:data_source=/api/v1/devices?limit=200&expand=userSummary – This tells OnLink to call the Okta Devices API (with a limit of 200 per page and an expansion to include the user summary). By default, OnLink would call the users API, but here we override it to the devices endpoint .
  
  
• The mappings like map:profile.displayName, platform, manufacturer, etc., correspond to fields in the device object returned by Okta. They map to attributes in the Assets Device object (e.g., Device Name, Device Platform, etc.). This will capture the device’s key properties.
  
  

The lines with _embedded.users.0.user.profile... are mapping data about the user associated with the device. Okta’s device API embeds the user info for the primary user of the device (under a userSummary). In this example, we map the first name, last name, and email of the embedded user to the Device object’s attributes for owner’s name and email. Alternatively, you might map the user’s email to a user-type attribute to directly link the Device object to the User object in Assets.

End to End Demo

👉 Try OnLink today to connect Okta with Jira Service Management. If you’re using Okta as your identity provider and JSM for your ITSM, OnLink can bridge the two by importing your Okta data into Assets and enabling automation for identity-related tickets. With a few clicks, you can set up the sync and start resolving access requests faster and more effectively. Please give it a try and let us know your feedback.