ISC - Webservice Update Account via SCIM API Returns Success but Does Not Apply Changes

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hello,

We are using a Webservice connector where we need to call a different endpoint to update account attributes.
To do so, I use a custom curl request, and it works correctly for most attributes.

However, one attribute (jobCode) located under a SCIM extension is not updated, even though:

  • The operation returns success in ISC (no errors in logs).
  • The same request works perfectly in Postman.

Here is the curl request I’m using:


curl --location --request PATCH 'https://x/v2/Users/$plan.nativeIdentity

--header 'Content-Type: application/json' \
--header 'Authorization: Bearer $application.access_token
--data-raw '{
  "Operations": [
    {
      "op": "replace",
      "path": "name.givenName",
      "value": "$plan.Firstname$"
    },
    {
      "op": "replace",
      "path": "name.familyName",
      "value": "$plan.Lastname$"
    },
    {
      "op": "replace",
      "path": "emails",
      "value": [
        {
          "value": "$plan.Email$",
          "type": "work",
          "primary": true
        }
      ]
    },
    {
      "op": "replace",
      "path": "urn:ietf:params:scim:schemas:extension:criteo:2.0:User:jobCode",
      "value": "$plan.jobCode$"
    }
  ]
}'

Do you know why this SCIM extension attribute is not getting updated when the request is triggered from ISC, despite receiving a 200 OK response?

Thanks in advance for your help.

2

@ragavi , can you try by giving “content-type” as “application/scim+json”? Not sure if this helps. Also dies the plan has jobcode attribute?

3

I would suggest you to test the API through Postman before implementing in SailPoint. Check the API behavior first.

4

Hi @ragavi,

Thanks for sharing the detailed scenario. It would be helpful if you could share the SCIM API documentation or name of application connected if applicable.

Silent failure (200 OK, but no update) is especially tricky with SCIM extensions. If I may suggest: -

  1. Make sure $plan.jobCode$ is actually resolving to a valid value at runtime as @JackSparrow mentioned. Empty or malformed value, are at times silently ignore by APIs (especially in SCIM PATCH). What happens when you pass null/empty string for jobCode in Postman?

  2. Try adding schemas as some SCIM APIs are strict about schema declarations. Postman might tolerate missing schemas: -

curl --location --request PATCH 'https://x/v2/Users/$plan.nativeIdentity' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer $application.access_token' \
--data-raw '{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "path": "urn:ietf:params:scim:schemas:extension:criteo:2.0:User:jobCode",
      "value": "$plan.jobCode$"
    }
  ]
}'
  1. Try isolating the failing operation. Remove the other operations from the PATCH temporarily and send only the jobCode.

Good luck mate.