I implemented a SCIM 2.0 integration with Okta according to the examples listed in their documentation.
However, we are getting an unexpected request for a use case. If Okta sees that the user already exists but is deactivated we get a request to the /Users/{id} endpoint with the following payload:
{
"totalResults": 1,
"startIndex": 1,
"itemsPerPage": 1,
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:ListResponse"
],
"resources": [
{
"name": {
"formatted": "John Does"
},
"emails": [
{
"value": "test@email.com",
"primary": true
}
],
"externalId": "113",
"active": true,
"id": "113",
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User"
]
}
],
"Resources": [
{
"name": {
"formatted": "John Does"
},
"emails": [
{
"value": "test@email.com",
"primary": true
}
],
"externalId": "113",
"active": true,
"id": "113",
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"natsRole": "nats/v1"
}
],
"active": false
}
The payload of this request uses the schema urn:ietf:params:scim:api:messages:2.0:ListResponse. Because the URL pattern mandates an update to one user this seems like it may be a bug on the Okta side, but I am wondering if this is part of the SCIM spec or if we are getting this call from Okta due to a misconfiguration (I have it setup to support Push New Users and Push Profile Updates only).
Is this a bug or by design? If it is, would a spring boot controller integration need to accept a dynamic RequestBody that could be one of two schema types?
As part of the SCIM contract, a GET /Users/{id} endpoint should return a json body representing the User. I was erroneously returning the json body for a /Users?filter call: ListResponse.
On the okta side, before updating a user's details they GET /Users/{id} the current user data, merge their changes in, and call the PUT API. It seems that, upon getting the wrong GET details, Okta merges the changes into that response and sends it back to the user.