SCIM Provisioning sends unexpected payload for user deactivation

Question

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": "[email protected]",
          "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": "[email protected]",
          "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?

Answer 1

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.

Answer 2

If you are the SCIM server/service provider and Okta is the SCIM client, and the quoted JSON payload is from Okta's SCIM client - then Okta's SCIM client is incorrect. The ListResponse structure is only used for certain responses from a SCIM service provider, never for a request from a client.