Hi a36f454ed576,

We are trying to automatic our off boarding process.  We are able to remove terminated users from group through API.  How do you setup your JSM instance to revoke user for site access when not part of any group?  Does JSM user portal site access consider as publicly accessible site?

Luca, my instance is configured so that users must be a member of at least one group to have site access. As soon as a user's group list is empty, site access is automatically deactivated. Give it a shot on your instance. I hope it behaves the same way for you. If not, there is likely a way to configure it to restrict site access to only group members unless you specifically require a publicly accessible site. In that case, my workaround sadly won't work for you.

Hi a36f454ed576, 

Thanks for sharing the workarounds.
I have a question on the api-based workaround that consists in removing each user from all groups. 

A user may have site access while not being part of any groups. Could you please outline the solution you applied which results in automatically revoking a user's site access when all groups are removed from their account?

Thanks a lot,

Luca Calderone 

Jira Administrator
 

Thanks, Greg, Richard,

I appreciate your suggestions.

Using the script from  21/Dec/2022, or using the REST API to remove people from groups both look valid.

(1) The users are not assigned to any group, so that they will no consume a license. However, when they log there is come confusion over site access and product access. They question why they can log in to a site, but not access Jira or Confluence. This causes confusion.

(2) The main difficulty is internal security policy. We need users to be applied to a certain security policy for access to our site. We have 26,000 users applied to no groups thus do not have product access; however, they do have site access. When performing a security audit, it adds a level of ambiguity that users with site access are not applied under the security policy because they do not have product access.

We should be able to remove this ambiguity by removing site access entirely. This would also be easier to explain during security audits.

I would also prefer that Atlassian provide this functionality via there REST API, rather than needing a bespoke node.js script (although I very much appreciate you providing this).

@Mathew Maylin, another workaround that is strictly api-based is to remove each user from all groups. When a user is not in any groups, it automatically removes their site access and that user will no longer consume a seat license.

What I do is run a script that accepts a list of Atlassian IDs that I want to deactivate. First I loop over each Atlassian ID and collect that user's groups. Then I loop over each group, and use the Remove user from group API to remove the user from that group. It takes several minutes to cycle through every group for every user, but it works.

One caveat, is that before I remove all of the users from all groups, I always save an export of the users and their groups using the "Export users" feature in Atlassian Admin, and I select the "Group membership" option under Additional Data. That way if any of those users ends up needing their access back, I have a reference of exactly who was removed and which groups they were in before I did my license cleanup. I hope that helps!

For what it's worth, the work-around I posted at 21/Dec/2022 9:47 AM is still working, and we use it regularly to disable access for people who've not accessed the site recently. It may be appropriate if your 26,000 users is a one-off.

I need to revoke site access to 26,000 users. This would take a prohibitively long amount of time to do manually.

The bulk operation should be provided via the UI as a basic tool for administrators. It should also be provided via REST API.

I have reviewed BulkOps and this is not a valid solution due to data privacy of my users.

Incredibly insecure API design for revocation to not be possible programmatically. Please, can we get an update?

We also need this functionality to keep our licenses under control in an automated way.

Just from looking at the API requests being made from the web UI. They're strings such as 

'jira-software' for Jira and 'conf' for Confluence.