Hi Folks,
I’m buzzing with excitement now that the time-based device admin is GA - probably the most anticipated feature over the past years.
Here is why I’m thrilled: imagine firing off a Jira request for admin permission -> access granted for a desired time span automatically -> tracked and documented -> revert back the permission once expired. It's like a dream come true!
Before we dive into that, let’s get a brief look at the API endpoint behind the scenes, which is the heart of this whole process. In case you consider adopting the same concept on another platform than Jira, totally possible.
Overview of JumpCloud’s Time-Based Admin API
API Url: Create Access Request
To avoid overwhelming, I'll briefly explain the key part of this API—how to construct the body for this request:
{
"requestorId": “USER_ID", # JumpCloud User ID, can be retrieved by systemuser endpoint https://docs.jumpcloud.com/api/1.0/index.html#tag/Systemusers
"resourceId": "SYSTEM_ID", # JumpCloud System/Device ID, can be retrieved by system endpoint https://docs.jumpcloud.com/api/1.0/index.html#tag/Systems/operation/systems_list
"resourceType": "device", # Fixed Value
"remarks": "", # Optional
"expiry": "2024-03-13T13:57:45.497Z", # An UTC timestamp in the future
"operationId": "ff487bda-e18f-42ed-9d6c-5c7cafd6adf9", # Fixed Value (for now)
"additionalAttributes": {
"sudo": {
"enabled": true, # Enabling Admin privellege on the device
"withoutPassword": false
}
}
Now, let's see how to use it in Jira Automation.
Setting the Stage with Jira Automation
Step 1 - Create a custom field in Jira to capture the requested time from the user, let’s call this field “expiry”.
Step 2 - Create the automation rule.
- Once the change has been saved, head over to “Project Settings” -> “Automation” -> “Global administration”.
- I recommend using this setup for testing purposes only and tailoring the automation to fit your specific IT environment. Here's a high-level overview of what I built:
- For the first module - “Then: Send web request”, the URL should look like this:
https://console.jumpcloud.com/api/systemusers?filter=email:$eq:{{issue.reporter.emailAddress}}This will capture the requestor’s email which should match the JumpCloud user if Jira and JumpCloud are integrated.
-
Now, for the next - “And: Send web request”, customise the request body like this:
{ "expiry":"{{now.plusMinutes(issue.expiry).format("yyyy-MM-dd'T'HH:mm:ss'Z'")}}", "requestorId": "{{userid}}", "operationId": "ff487bda-e18f-42ed-9d6c-5c7cafd6adf9", "resourceId": "{{systems.id}}", "resourceType": "device", "additionalAttributes": { "sudo": { "enabled": true, "withoutPassword": false } } } - You may construct the rest of the rule as I did above.
- Now, test it with creating a new request:
- And voila!
On JumpCloud:
Wait, There is More!
If you happened to have Slack <> Jira integration setup as well, you will receive a notification like this in Slack:
Looking to the future, since JumpCloud captures the user attribute of a manager, perhaps we can leverage this hierarchy to create an approval flow with Jira and Slack? It’s totally possible with the JumpCloud’s systemuser API.
That’s it, and I hope you like this idea. See you again soon!
Disclaimer: Please be aware that this post is based solely on my personal experiences and best knowledge of various products, independent from JumpCloud’s official resources. JumpCloud does not guarantee the accuracy of this content and is not liable to provide support for any issues that may arise from its use. If you encounter any challenges, I encourage you to discuss them in the comments. Let's leverage our collective knowledge to enhance our use of JumpCloud and continue inspiring each other in the community!
