We are experiencing issues with SCIM group push from Okta to a custom app.
After users are deactivated, they still appear in the list of group assignments (SCIM HTTP PUT) for any specific groups they were part of at the time of deactivation. This also happens after the deactivated users are removed from the groups after deactivation. Manually triggering group push for a specific group solves the issue.
The user profile (including termination date) are sourced from Workday.
This is an example flow:
- “Last day of work” (termination date) is set in Workday
- Profiles are synced from Workday
- Okta triggers user deactivation due to “Last day of work” having passed
- As part of this, Okta de-provisions user from app and makes a SCIM request to the app to disable the user
- Okta sends HTTP PUT with updated groups to the app through SCIM (2x HTTP PUT)
- These request includes group assignments for the deactivated user
- Okta runs a scheduled workflow to remove deactivated users from all groups
- As part of this, the user has all group assignments removed in Okta
- Okta sends HTTP PUT with updated groups to the app through SCIM (2x HTTP PUT)
- These request still includes group assignments for the deactivated user
- A user triggers a “force push” on the group directly from Okta, which triggers SCIM requests (2x HTTP PUT)
- These requests do not include the group assignments for the deactivated user
This shows us that regular SCIM group pushes (automatically executed by Okta) work differently when done automatically or manually. The automatic group push includes stale data (invalid group assignments) that are not included when we trigger force sync. This appears to be a bug on Okta’s side – we would expect automatic and manual group push to produce the same result.
This leaves us a few options, most of which would require changes on Okta’s side;
1. Manually remove users from groups before deactivation
According to the Okta docs, users should be removed from groups before being deactivated [0]. This would require us to replace an automated process (dectivation from Workday) with a manual and error prone manual process.
This is not an acceptable solution.
2. Remove users from groups before activation through inline hook
We could tie the group removal workflow to an inline hook that’s triggered on deactivation.
However, there does not seem to be any inline hooks available for this scenario, meaning that we cannot add logic to handle group assignments automatically as part of deactivation.
3. Global feature to remove groups during deactivation
A lot of different actions kick off when a user is disabled. A possible solution would be to add an option to trigger revokation of all group assignments when a user is deactivated, before app de-provisioning.
We understand that a lot of customers depend on the current logic, but we also think that this could be handled globally within the tenant by a feature toggle.
4. Fix bug in SCIM groups dataset
The content of SCIM group push (HTTP PUT) differs between automatic push actions and manual ones. We believe this to be a bug, and that removing group assignments for a disabled user could leave the assignment in the SCIM group push payload. Triggering a forced group push for the specific group would rectify the issue.
Fixing this bug would make the automatic group push work correctly.
How should we proceed, and what solutions could be feasible long term?