Okta - User reactivation does not remove old groups from user profile

[#1]

Issue Summary

When admins remove users from all groups, Okta will deactivate the Atlassian Account. Okta does this by updating the account activation status to false on Atlassian.

Atlassian will preserve group membership since the IdP only pushed an account status change. 

This becomes an issue if, on reactivation, the user gets added to different groups than they belonged originally. Okta does not automatically trigger group removals.

Steps to reproduce:

1. User testexample@somedonain.com belongs to the group Production-Confluence; the group is assigned to Atlassian Cloud app on Okta

2. Admin removes the user from group Production-Confluence

3. Okta will deactivate the Atlassian Account; Atlassian will keep the group membership with the user deactivated

4. Admin reactivates user testexample@somedonain.com but is now on Production-StatusPage by adding the user to that group. This group is also assigned to Atlassian Cloud app on Okta

5. Okta changes the activation status of the account and adds the group Production-StatusPage to the user profile

6. The user now exists in two groups on Atlassian side, Production-Confluence, and Production-StatusPage, and will remain in that state until a Push Group is performed from the group that was removed from the user profile (Production-Confluence)

Workaround:

• Perform a Group Push on the group removed from the user profile.

Okta does not have a provisioning cycle where it refreshes group membership. This is only done if a group push is manually triggered.

UPDATE: We received communication from our customers that Okta has a flag  (GROUP PUSH INACTIVE APPUSER) that their engineering can enable on your tenant where user reactivations are handled differently:

• The flag will push the group membership when the appuser is in active or pending status or inactive status. When inactivate the user and change the membership at the same time. It will check for inactive users during a partial group push and push them downstream, provided of course the members are in a state of not pushed yet. The feature should not affect anything else in your configuration.

[Kieren]

@Fernando S This workaround is good to force other sync'd groups to be updated. But it doesn't address non-sync'd groups.

e.g. User A exists in the jira-software-users group, and that user is deactivated and removed from the sync'd groups. But they won't be removed from jira-software-users. If that user is reactivated, then the user will suddenly get access to Jira Software as they're already in that group.

I've not need any solution for this issue, but let me know if there's one out there?