Is there a Cloud API yet to revoke access to the product/Instance for either managed or unmanaged ac

Question

Is there a Cloud API yet to revoke access to the product/Instance for either managed or unmanaged accounts?

ie the Have Access Switch accessible via the REST API

Seems strange that this ability is available in Server but is still not available in the cloud version.

* Delete only works if they have not made a comment, assignee or reporter.
https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-users/#api-rest-api-2-user-delete
* Remove user from group, is fine but they are still marked as active.
https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-groups/#api-rest-api-2-group-user-delete
* Deactivate user only works for managed domain accounts, and only if not integrated with SSO and deactivates the managed user from every Atlassian product, not just the instance
https://developer.atlassian.com/cloud/admin/user-management/rest/api-group-lifecycle/#api-users-account-id-manage-lifecycle-disable-post

Just looking for a cloud version of the server PUT version that allowed you to set the active status to either true or false

ie Cloud version of: https://docs.atlassian.com/software/jira/docs/api/REST/8.3.0/#api/2/user-updateUser

curl --request PUT \
--url 'https://your-domain.atlassian.net/rest/api/2/user' \
--user 'email@example.com:<api_token>' \
--header 'Content-Type: application/json' \ 
--data '{ 
"accountId": "{accountId}",
"active": false
}'

Is there any other workaround to perform this via API/Automation?

There are multiple tickets and threads on this, and seems strange that this still cannot be done.

Part of this work is so that we can implement least privilege for people to onboard and offboard users, without making them site admin, trusted or product admins.

As those roles/groups provide too much access, and allow those users to add marketplace apps without permission, and change permissions, etc

We have already had several incidents with those roles, so we are looking for a different way to onboard and offboard.

Currently have project with linked automations that:

Only user in a certain group can resolve the tickets, and the automation kicks off at the relevant ticket resolution.

* Onboarding* Adds user to instance,
* adds user to AAD,
* adds user to relevant AAD groups,
* adds non federated users to relevant Atlassian groups

* Offboarding* Left the team* Removes from AD Team group(s)
* Removes from Atlassian Team group(s) - for non federated domain users

* Left the business* Removes from all relevant AD groups
* Removes from all Atlassian groups
* Attempts to Deactivate user
* Attempts to Delete the user
* Moves user to a dummy group, where they can be manually switched off  (active to false)
Which prevents mistaken or disgruntled re-access.

What would be great is for this to be achievable via the REST API, in a similar way the existing server version that can do it

Nika Alavidze · Answer

I got to this question when looking for a similar but not same problem.
I need to locate user that have been inactive for certain period of time and if threshold is met - revoke their product access. e.g if user has not used Jira Software for 6 months - remove access to jira.

I manually located one such user and tried removing them from jira-software-users group  via REST API but I get error that this is the last default group for user. Basically preventing me from kicking them off the product but that is exactly what I need.

In addition I need to see the last active dates and both functionality is available through admin api but they are only available for managed users The Organizations REST API REST API (atlassian.com)

So basically I need to see last activity of unmanaged users and remove their access to product in an org but cannot seem to find the solution.

ELFAPP Technologies · Answer

Hi,

One of the things you have to understand about the cloud is that there are unmanaged and managed users. The latter is users that are provisioned with an identity provider. The former is local to the site where the user is added.

I believe you're looking at deleting users if possible but deactivate them when needed. Just an added context here is that no user is technically deleted from any Atlassian product except there's a formal request to completely delete the user (rights to be forgotten which takes some days) which basically removes all traces of the user profile from all Atlassian products used. The API to delete will basically change the flag from active: true to active: false behind the scene and removes the user from a UI view if the formal request isn't used.

Back to your question, there's no public API that allows you to suspend a user from a single site as the recommended way to go about it is to remove application access. Then eventually have an automation that would either delete the user (if unmanaged) or deactivate (if managed) when they leave the team or business. The problem you might have with deletion is tickets or issues that are still in progress, which will force the user not to be deleted via the API. This also stems from other issues about how projects are configured and managed but keeping it simple by removing the users from groups achieves the same purpose. You mentioned the state of active still shows true but when done, you have the option to either delete or deactivate the user. The reason I mentioned group removal is that in Jira, certain group access is what gives the user application access. If that application access is removed, the user cannot perform anything on that Jira site. This gives you the flexibility to perhaps manage the user if they are on another site. This way, you do not completely disable the user if they are working with a different team on another Jira site.

Therefore, your automation should be relatively simple enough to remove users from groups that they belong to and ultimately deactivate users if they leave the business. The current APIs you highlighted do all these, so it depends on what steps you want to take next. Jira Server/DC is completely on its own sphere as you typically manage the entire infrastructure so you're more intune to turn the tables upside down if you want. However, on cloud it follows a structure that caters to best security practices and how users should be treated within organizations. I believe when you realized that active Jira issues prevented your users from being deleted was a step back but the logic behind that is actually proper as it helps to ensure proper configuration happens at the project level and to prevent other issues with user association, activities etc.

Also, you might want to reaccess how users are given permission within your organization. Higher tier groups (such as site-admin, trusted user etc.) should be reserved for selected users who require it and not everyone or team who requests for it in your organization.

Lastly, your request is very much achievable with the current API but you also need to look into other problems which are not associated with what you're trying to solve.