We are testing our SCIM API integration at the moment. We have noticed the following scenario:
User is removed from application, and Okta logs “Remove user’s application membership” then “Push user deactivation to external application”.
User is added back to application, and Okta logs “Verify user exists in external application”, “Push user reactivation in external application” then “Push user’s profile to external application”.
The third step in 2 fails, reporting an error to you (we are working on this part of our system now).
User is removed from application again, and Okta only logs “Remove user’s application membership”.
It seems that if the last update for a user returned an error response, Okta does not send the “Push user deactivation to external application” request when you attempt to remove the user from the application. The user is therefore not removed from our application.
Could someone please confirm if this is as intended?
Yes, this is intended. If a user provisioning to an app fails (eg. on step 2) , then Okta will not link it with the SCIM server and, as a result, the primary ID of the user in the SCIM server will not be saved in Okta as external ID.
On step 4, because the user does not have an external ID attached, there will be no deactivation request sent to the SCIM server.
In our case, in step 2, “Push user reactivation in external application” succeeds, which means that our application has returned an external ID and believes that the user has been activated. It is only the second request “Push user’s profile to external application” (which must be using that external ID in order to send the request in the first place) which fails.
Is there any way around this? At the moment, if that second request does fail, we are ending up with users on our application getting out of sync with Okta.
There is no option unfortunately to have a workaround, the application must implement the responses to the requests from Okta for the second reassignment.
Our current implementation of our SCIM server handles requests asynchronously, and refuses a second request for a given resource until it has finished processing its current request. Our issue is that the “Push user reactivation in external application” request is accepted by our server, but hasn’t finished processing when the “Push user’s profile to external application” request is received. If we retry “Push user’s profile to external application” from the Tasks screen a couple of seconds later, it works. We are going to work on improving this so that we can queue the requests on our system even if the first hasn’t finished processing.
The CRUD runscope tests are also currently failing on the final test for this reason. Will we be unable to submit our app to the OIN before this has been fixed? We were hoping there might be some leniency, so that we can submit prior to our main release, and keep the app private, in order to allow some full system testing and for our operations team to become familiar.
You can provide this details in the OIN submission and our Applications Team will give you further details regarding the integration process and the possibility to have the application private until the issue is fixed.