Hi ,
I am facing one issue while SCIM App Assignment for the Groups. This is what the behaviour :
Create a OKTA group with 2 users
Assign the group to a SCIM enabled app
Both the users are created fine , but group link is shows as empty (Not sure if that’s expected)
Removed one of the user from OKTA group
SCIM User has been updated with “active”: “false”
Add back the user to the OKTA group
*OKTA trying to make CREATE call to /Users , which returns as 409 conflicts
Questions -
Why the group show as empty when I am pushing a user through group assignments?
Why OKTA calling Create call instead of Patch or PUT ? How does this scenario is going to work as for CREATE my SCIM API would return error as 409 coflicts?
Not sure about your first question, what is group link you are referring to?
You have to remove/disable your user on activate: false event in your SCIM app. Ideally deleted from the app DB. But if you want to keep it, next assignment in Okta, which result in Create, should actually be preceded with Search for a user event. Are you 100% sure that you do not receive Search a user event before that?
Hi Philipp,
Thanks for your response. I have put more details to clarify the ask -
I have created a OKTA group (named: test) which is having 2 Users. I have assigned the test group to my SCIM Integrated App. I could see the Users and Group are created followed by GET call for each of the users. But the “groups”: is empty for both of CREATE payloads. My question is : why this is sent as empty when the Users are part of “test” group ? Also , is it expected behaviour that OKTA doesn’t call CREATE Group call for Group Assignment?
Ignore this , I found some issue related to initial GET call , I presume after that OKTA should be calling PUT/PATCH to reactivate the user.
I am running into the same issue(#2). This look like a limitation in Okta. I am not seeing any attempt to check if a match exists in the App, before it issues the POST /Users which fails(User already exists in App).
Since I am working on an App to submit to OAN, I had to modify the RunScope script CRUD test, I had to insert a DELETE {{SCIMUrl}}/Users/{{scim_id}} Step, and then a clone of the GET {{SCIMUrl}}/Users with filter on userName to retrieve the new scim_id after Okta creates the User again with the POST /Users call.
The recommendation from Okta seems to be to manually delete the User in App before reactivating/reassigning the App, a step that needs to be added to the script.
there should always be a search call before okta attempts to create the user.
you can inspect the http requests going on at that point as probably the response back on that call is not one that okta expects and interprets it as there is no such user already