Mapping Azure AD (Entra ID) Users with Jira Users and Jira Groups
The Assets module of JSM provides amazing features. Two of the useful capabilities are being able to define attributes as a “Jira User” type and/or “Jira Group”. Even though they are not a part of the external import flow used by our applications, on this page, we will explore the ways to leverage these.
The example use case could be as follows:
Use Case:
As an Asset and Configuration Manager, I would like to keep track of all the Microsoft Entra ID (a.k.a. Azure AD) User records and extend them by adding their Jira User and Jira Groups information.
The same use case is valid for our other applications that store user-related information, including Okta, Google Workspace, Intune, Jamf, Snipe-IT, Salesforce, Hubspot, Database, etc. We will provide 2 different methods to map Entra ID (Azure AD) users with Jira Users and Jira Groups in JSM Assets as an example. You may apply the same logic for other data sources you may have.
This would be very handy if you configured Atlassian Guard (a.k.a. Atlassian Access) and already have sync configuration for the Users and Groups from your IDP.
Prerequisite: Atlassian Guard (Atlassian Access) subscription connected to your identity provider (IDP).
Benefits
One of the benefits of having the Jira User as an attribute of the Users (or other object types) would be using the Filter Issue Scope AQL of an Assets Custom Field to allow the requestor to view the records mapped for their user. Here are some examples:
Case | Filter Issue Scope AQL to be used | Example Object Types |
---|---|---|
You have an object schema where you have Users or People as Object Type having a “Jira User” attribute. |
| Azure AD (Entra ID) Users Okta People Google Workspace Users Salesforce Contact Person Hubspot Contact Intune Users Jamf Users Snipe-IT Users Datadog Contacts Tempo Jira Users |
You have an object type that stores device related information (for example Intune “Managed Devices”) and has an attribute called “Owner” related to the “Users” object type which has “Jira User” attribute. |
| Intune Managed Devices Jamf Computers, Mobile Devices Google Workspace Mobile Devices, Chrome OS Devices Snipe-IT Assets Okta Devices Datadog Services |
Instructions
The following are just 2 possible examples to fulfill the use case.
You may follow different paths depending on your needs:
Start with Option 1 and then continue with one of the following
Scenario 1
Scenario 2
Start with Option 2 and then continue with one of the following
Scenario 1
Scenario 2
Option 1:
Update objects instantly when they are created or updated and set the Jira User and/or Jira Groups.
Install Azure AD (Microsoft Entra ID) Importer for JSM Assets from the marketplace.
Watch the demo.
Configure and import your organizational data (i.e. Users and Managers)
Set the scheduling for automated replication.
Select your “Azure AD” object schema and “Users” object type. Select “Attributes”.
Add one new attribute to the end and name it as “Jira User”. Set the type to “User”.
[Optional. Needed for Scenario 2] Add another attribute for “Jira Groups” and set the type to “Groups”. Edit the attribute properties and set the cardinality as unlimited.
Add one more attribute to the end, and name it “Previous E-mail Address”. You will use this attribute to understand when a user's email address changes.
Add the last attribute and call it “E-mail Check Date“ to store the date information when the automation rule runs.
Create an automation rule at the Global level with the following steps.
Automation Component | Configuration | Explanation |
---|---|---|
|
| Select the trigger for Object Trigger and click “Created“ tab. Select “Azure AD” object schema. |
|
| Check if the updated object is one of Users and has an email address.
|
Search for the user’s “Jira User” record using the Jira Rest API and get the accountId. Send a GET web request to Jira API using the URL:
Add a header called Authorization. Enable the Hidden checkbox. The hidden part in the header needs to be in a format like:
Please note that your Email Address and API Token need to be Base64 encoded, as explained in the following document. | ||
| Make sure that you found only one record. Check |
We recommend using the “Log Action” component between the steps above to see if you have mapped the fields properly and the data is flowing as expected. This will save time while you are troubleshooting your rule.
Pros:
Updates objects as soon as they are created in Assets.
Cons:
The trigger is set for “Object Created” event only as an example. You need to cover the updated objects too.
If you have a very large user base and thousands of user creations or updates occur daily, this trigger may hit the Jira Cloud automation limits and fail. Option 2 below could be a better solution in that case.
Automation Component | Configuration | Explanation |
---|---|---|
| Select the trigger for Object Trigger and click “Updated“ tab. Select “Azure AD” object schema. | |
| Check if the updated object is one of Users and has an email address.
| |
|
| Add an If block to check at least one condition matches: Condition 1: {{smart values}} condition
does not equal
This means the email address of the user has changed recently. Condition 2: AQL condition
This means the user record doesn’t have a “Jira User” mapped yet. |
Search for the user’s “Jira User” record using the Jira Rest API and get the accountId. Send a GET web request to Jira API using the URL:
Add a header called Authorization. Enable the Hidden checkbox. The hidden part in the header needs to be in a format like:
Please note that your Email Address and API Token need to be Base64 encoded, as explained in the following document. | ||
| Make sure that you found only one record. Check |
If you successfully came to this step, you should have 2 automation rules ready to run on Object Created and Object Updated conditions. From this point, please follow Scenario 1 or Scenario 2, described at the bottom of this page, to complete your automation rules. Don’t forget to do the same for 2 rules.
Option 2:
If you have a scheduled Azure AD import configuration in your Azure AD Importer for JSM Assets application then there is a chance that the Jira User is not created at the time of Azure AD import. Another case can be that high number of records are being updated and it is not feasible to use Option 1. In such cases, this requires the mapping to be performed not in real-time but periodically (i.e. hourly or daily).
Follow the same steps as Option 1 above until Step 10.
Create an automation rule at the Global level.
Automation Component | Configuration | Explanation |
---|---|---|
|
| Decide on the best scheduling frequency for your environment. If you have few users, then once a day (i.e., every night at 03:00 AM) could be sufficient. On the other hand, if you have thousands of records, then you need to check more frequently (i.e., every 30 minutes). You will find the best schedule configuration after you try the rule several times. |
There will be two branches in this automation. Here is Branch 1: | ||
| Find the Users in the “Azure AD” object schema which don’t have the Jira User defined Use the AQL:
| |
|
| Search for the user’s “Jira User” record using the Jira Rest API and get the accountId. Send a GET web request to Jira API using the URL:
Add a header called Authorization. Enable the Hidden checkbox. The hidden part in the header needs to be in a format like:
Please note that your Email Address and API Token need to be Base64 encoded, as explained in the following document.
|
| Make sure that you found only one record. Check | |
Here is Branch 2: | ||
|
| Find the Users in the “Azure AD” object schema which are updated by the automation rule more than 1 day ago. Use the AQL:
|
|
| Search for the user’s “Jira User” record using the Jira Rest API and get the accountId. Send a GET web request to Jira API using the URL:
Add a header called Authorization. Enable the Hidden checkbox. The hidden part in the header needs to be in a format like:
Please note that your Email Address and API Token need to be Base64 encoded, as explained in the following document.
|
| Make sure that you found only one record. Check |
Now, your rule should look like the following:
From this point, please follow Scenario 1 or Scenario 2, described at the bottom of this page, to complete your automation rules.
Pros:
Updates objects periodically.
Cons:
Updates 50 records in every execution. If you have a very large user base, it could take some time for all the objects to be updated.
Scenario 1
Add the following step after each smart value comparison step checking {{webResponse.body.size}}
in your rule(s).
Automation Component | Configuration | Explanation |
---|---|---|
|
| Edit the object 1- Set the Jira User attribute using the Smart Value:
2- Set the Previous E-mail Address.
3- Set the E-mail Check Date:
|
Scenario 2
Automation Component | Configuration | Explanation |
---|---|---|
| Create a variable as | |
|
| Send a GET web request to the following URL: This request collects the list of Jira Groups for the user from Jira Cloud platform. |
|
| Make sure that the response has the information needed by checking |
| Collect all the Jira Groups in to a variable called | |
|
| To be able to update the object, first, you need to find the Workspace ID for your Assets environment by sending a GET web request to |
Create a variable as for the | ||
Not a step in the automation |
| Check the Object Type configuration for your Users object type and get the ID. In the screenshot, you will see that it is 133 for our demo site.
|
Not a step in the automation | Take note of the object type attributes for the new attributes you created. You may copy them from the attribute view by clicking the copy icon on the right. | |
| Add a new step to update the Object. Send a Select the web request body as “Custom data“ and copy paste the following JSON. Update the object type ID and attribute IDs accordingly. | |
{
"attributes": [
{
"objectTypeAttributeId": "3555",
"objectAttributeValues": [
{
"value": "{{jiraUserAccountId}}"
}
]
},
{
"objectTypeAttributeId": "3558",
"objectAttributeValues": {{jiraGroups}}
},
{
"objectTypeAttributeId": "3981",
"objectAttributeValues": "{{object."E-mail Address"}}"
},
{
"objectTypeAttributeId": "4029",
"objectAttributeValues": "{{now"}}"
}
],
"objectTypeId": "133"
}
| ||
|
| Add the response status code to the Audit log as You should see “200” in the logs if everything is fine. |