Mapping Azure AD 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 which store user related information including: Okta, Google Workspace, Intune, Jamf etc. We will provide 2 different methods to map 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 in case you are using Atlassian Access and already have sync configuration for the Azure AD Groups.
Prerequisite: Atlassian Guard (Atlassian Access) subscription connected to your identity provider (IDP).
One of the benefits of having the Jira User as an attribute of the Users object type would be using the following as Filter Issue Scope AQL of an Assets Custom Field to allow the requestor to view the records that are mapped for their user:
"Jira User" = currentReporter()
The following are just 2 possible examples to fulfill the use case.
Instructions
Option 1:
Update objects instantly when they are created and set the Jira User and 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 the “Azure AD” object schema and “Users” object type. Select “Attributes”.
Add one new attribute to the end and call it “Jira User”. Set the type to “User”.
Add another attribute for “Jira Groups” and set the type to “Groups”. Edit the attribute properties and set the cardinality as unlimited.
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 newly created object is one of Users.
| |
| Search for the user’s “Jira User” record using the Jira Rest API and get the accountId. Send a web request to Jira API using the URL:
The hidden part in the
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 the value for |
From this point please follow Scenario 1 or 2 described at the bottom of this page to complete your automation rule.
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. The second option below could be better in that case.
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. 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 7.
Create an automation rule at the Global level.
Automation Component | Configuration | Explanation |
---|---|---|
|
| Select the rule trigger for “Scheduled”. Define the schedule period. I.e. every day at 3 AM GMT or hourly. |
|
| Select the 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 web request to Jira API using the URL:
The hidden part in the Authorization 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 |
From this point please follow Scenario 1 or 2 described at the bottom of this page to complete your automation rule.
Pros:
Updates objects periodically.
Cons:
The AQL condition checks if the Jira User attribute is empty. This doesn’t cover the cases where a user is deleted from AD and created again with another email address.
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 only the Jira User to the object.
Automation Component | Configuration | Explanation |
---|---|---|
| Edit the created object and set the Jira User attribute using the Smart Value.
|
Scenario 2
Add the Jira User and the Jira Groups.
Automation Component | Configuration | Explanation |
---|---|---|
|
| Create a variable as |
|
| Send a 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 web request to |
|
| Create a variable as for the |
Not applicable: 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 449 for our demo site.
|
Not applicable: Not a step in the automation | Take note for the object type attributes for the new attributes you created. You may find them in the screenshot as 6037 and 6038 for our demo site. | |
| 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": "6037",
"objectAttributeValues": [
{
"value": "{{jiraUserAccountId}}"
}
]
},
{
"objectTypeAttributeId": "6038",
"objectAttributeValues": {{jiraGroups}}
}
],
"objectTypeId": "449"
}
| ||
|
| Add the response status code to the Audit log as You should see “200” in the logs if everything is fine. |