JIT Provisioning

[kc]

Am looking to achieve the objective of "zero standing access" where organizations can grant or elevate human and non-human users in real-time to provide elevated and granular elevated privileged access to an application or system in order to perform a necessary task. Instead of having or granting permanent "Org Admin" access to an individual. Not sure if JIT is in Atlassian Roadmap? I was told it can be achieve by customization using script + automation rules. 

[Kieren _SmolSoftware_ · Accepted solution]

Hi kc

I’m not aware of any JIT features in admin.atlassian.com that allow you to automatically control admin access.

But given that the organization admin permission is granted by adding users from the site-admin or org-admin group, you could use a script to call the organization APIs and add/remove users to those groups. Thereby granting or removing org admin access as necessary.

I don’t think these APIs are available for use via Jira Automation, and the Jira REST APIs that are usable via Jira Automation don’t allow changes made to ‘protected’ groups, like the site-admin and org-admin groups. You should test that to double check… Here’s an example of an automation using a Jira REST API.

Our Admin Automation app was built with a similar use case as yours. If you’re using SCIM to sync your users to your Atlassian products, you can configure the Admin Automation app to add or remove users from the site-admins and org-admins groups based on a SCIM group.

e.g. You can schedule a rule to run hourly to add users from an IdP group called temp-admins into the org-admins group.

And schedule a second rule to run daily/weekly/how ever often you want to remove all unnecessary org admins; If a user is not in the permanent-admins group (where one or two admins exist that have permanent org admin permissions), then remove the user from org-admins group.

Then you just need to trigger a group change in your IdP to get what you need. That trigger could be as simple as a manual task after an approval process (such as via ServiceNow or Jira Service Management).

Keep in mind, that if ALL org or site admins are removed from an org, then you risk your org getting into a broken state and you may have to raise a service ticket with Atlassian to get back into it. The permanent-admin group should prevent that from happening.

There are more details of the rule setup on our website if you’re interested.

I hope that helps!

-Kieren

Co-Founder @ Smol Software | Ex-Atlassian

[kc]

Thank you for your response. I'd like to provide further details to clarify our approach.

We aim to minimize the number of organizational administrators to three. Here's how we envision the process:

1. Access Control: Only the designated three individuals will maintain ongoing organizational or site administrative privileges. Should additional personnel require temporary admin rights to perform specific tasks, they may request access for a defined duration, such as one hour, specifying the date and time needed.

2. Elevated Permissions: The authorized personnel will receive a Jira link to elevate their permissions temporarily. Upon completing their task, they must mark the task as completed in the Jira ticket, triggering an automated process to revoke the elevated rights within the granted time frame.

3. Time Extension: If the task requires more time than initially granted, personnel can request an extension. This request must be approved by a different approver than the one who authorized the initial access.

Upon task completion, personnel should confirm in Jira, which will revert their rights back to standard, non-administrative levels.

[Darryl Lee]

Super interesting question and idea for a JIT process, @Kelvin CHUA. And I appreciate your detailed answer @Kieren _SmolSoftware_ Your product sounds compelling.

In our case, as we were migrating from Data Center to Cloud, we switched from using changed Atlassian default groups for Product Access to the same groups (provisioned using Azure AD syncing for nested groups) that we used in Data Center.

I did want to add that while it's true that Automation does not have built-in actions to use organization APIs, it does have a Send web request action that in theory, should be able to connect to the API you linked to and accomplish what @kc is looking to do.

I guess technically there's a danger that when a user has Org Admin rights, they may start poking around into the workflows and automations that grant elevated permissions. You'll want to make sure to set the Header with the "Authorization: Bearer" token (which is the Organization API Key) to be Hidden.

I guess if you were really paranoid about what a user did with their elevated permissions, you might set up some kind of audit mechanism.

Oof. Security is hard. Let's go shopping.

[Kieren _SmolSoftware_]

@Darryl Lee That's awesome, I didn't know about the Send web request action! I might look into incorporating that input into our app.

@Kelvin CHUA 

1. The Admin Automation app doesn't accept inputs from other systems, and the rules are general and fixed (i.e. they're not dynamic or able to be changed based on different inputs). If you are able to simplify your process; e.g. granting access for 1 day only, then it app should meet your needs. Otherwise you'd need to build something more custom to your needs with @Darryl Lee's suggestion.

2. You can use the Jira Automations and Jira REST APIs to trigger a user to be added or removed from a regular group (i.e. not a SCIM group). e.g. The Jira Automation calls the Jira Add User to Group API, to add a user into a non SCIM group called temp-admins. Then use the Admin Automation app to sync the temp-admins group into the org-admins group. And use a similar Jira Automation to remove the users from the temp-admins group and the Admin Automations app to remove any non-permeant users from the org-admins group.

3. Based off my #2 point comment, the user could request the temp admin role again, after it has expired. But as I mentioned in point #1, the Admin Automation app rules aren't dynamic yet and can't 'extend' or 'skip' a scheduled removal for a user. The only way to get this done would be via @Darryl Lee's suggestion.

I love complex problems, hit me up via email (you can find it via smolsoftware.com) if you want to discuss it in more detail KC.

I'm taking Darryl's advice too, time for some shopping 😂