SCIM Deactivation via Group Membership

Questions SCIM
1

Our QA noticed an odd artifact:

  1. Configure SCIM
  2. Add Group A to Push Groups
  3. Add Application to Group A
    a. Users in Group A are provisioned as expected
  4. Remove User U from Group A in Okta
    a. Deactivate is sent via PATCH
    b. User remains in Group A in application
  5. Add application to User U, either directly or by adding them to Group B
    a. User U remains in Group A in application, no remove is received

Our best guess is that Okta sees the user no longer has the application assigned, deactivates them, and then the Group removal is no longer relevant to the application, since they no longer have it assigned. Then when the user is re-added to the application, Okta does not do a “sanity check” to ensure the user’s Group Memberships are accurate.

Is our assessment correct? Is this a bug on Okta’s side or intended behavior?

1 Like
2

I’m also having a similar problem. Did you ever figure out what the correct thing to do in this situation was? How are users’s groups set when the user is not assigned to an application?

3

We’ve not yet figured out what the “correct” thing to do is, but we were able to confirm that when Okta deactivates a user it no longer updates the user’s details or Group membership.

We’re waffling between removing all Groups from the user on deactivation or just leaving them as-is, making the Okta admin re-push the Group every so often to true-up the membership.

1 Like