cancel
Showing results for 
Search instead for 
Did you mean: 

Time Based Device Admin - Privilege Elevation With Jira

shawnsong
Rising Star III
Rising Star III

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”.

shawnsong_0-1714465467981.png

shawnsong_1-1714465468060.png

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:shawnsong_2-1714465583467.png
  • 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.

    shawnsong_3-1714465671734.png
  • 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
            }
        }
    
    }
    
    shawnsong_4-1714465749291.png
  • You may construct the rest of the rule as I did above. 
  • Now, test it with creating a new request:shawnsong_5-1714465802525.png
  • And voila!shawnsong_6-1714465823342.pngOn JumpCloud:shawnsong_7-1714465839597.png

    Wait, There is More!

    If you happened to have Slack <> Jira integration setup as well, you will receive a notification like this in Slack:

    shawnsong_8-1714465864144.png

    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!



     

 

 

4 REPLIES 4

Jumpcloudtester
Novitiate I

Error publishing web request. Response HTTP status:

400
Error response HTTP body:
message":"error validating request: error validating CreateAccessRequest","status":"INVALID_ARGUMENT

1. Do I have to match the API key to be the same, getting this error? 
2. didnt use your branch and everything up the 2nd webhook
3. operationid: where do you get that or that can be the same as yours? is this where the error is coming from ? 

Hey @Jumpcloudtester , thanks for spending the effort testing it.

1. for `accessRequest` api endpoint, it has to be a writable API key - roles like JumpCloud Manager, or Administrator will do. 

3. yes, it's a fixed value: 

ff487bda-e18f-42ed-9d6c-5c7cafd6adf9

 you may share the sanitised request body here if the error persists using the ^ operation ID. 

rootsh
Novitiate I

How will it work if a user has more than one system?

Will it send multiple requests in the loop?

It will grant admin privileges for multiple devices in the loop. 

You Might Like

New to the site? Take a look at these additional resources:

Community created scripts

Keep up with Product News

Read our community guidelines

Ready to join us? You can register here.