Hello, I’m writing a SCIM integration to provision users into an existing app. My app doesn’t have the concept of a deactivated user that isn’t part of an organization - users can be in multiple organizations, and for a given organization, you’re either in the organization or you aren’t. As a result, when I get a PATCH request to make a user inactive, I remove them from the organization, and when I get a PATCH request to re-activate them, I add them back into the organization.
This means that when my SCIM server a GET request for a user that has been deactivated in Okta, I return a 404 instead of a 200 (since the user isn’t in the organization). This is failing the Runscope pre-submission test suite, and I’m wondering if it’s a hard requirement that users be able to exist within an organization in a deactivated state.
Thanks for your help!
You can uncheck “Deactivate” event to be delivered to your SCIM connector in Okta SCIM configuration page for the application. Then you won’t receive those calls, if I understood correctly what you are trying to achieve.
Thanks - I still want to receive the calls though, I just want to handle them slightly differently than Okta expects me to (removing them from my organization entirely, rather than leaving them in the organization in a ‘deactivated’ state).
At this point I’m not quite following the sequence of calls and the underlying business case.
To state the problem in a different way:
Okta assumes three possible states for a given user and organization: a) In the organization and active b) in the organization and inactive, and c) not in the organization.
My application only has two states for a given user and organization: a) In the organization b) not in the organization (no concept of active or inactive). A user can also be in multiple organizations.
I’m wondering if I need to add the third state to my application’s data model, or if it is acceptable to remove the user from my organization entirely when Okta marks them as inactive.
The sequence of calls is:
a) Okta provisions a user
b) Okta marks that user as inactive.
c) Okta checks to see if that user exists in the organization
Okta expects that call c) will still return the user but in an inactive state. I’m wondering if it’s a show-stopping problem if instead, my SAML API reports that the user is not in the organization at all (so it 404s instead of returning a 200 with “active”: False.
The underlying business case is just that it would take additional time and added complexity to add the third state I mentioned above into my existing application.