SCIM validation tool (https://scimvalidator.microsoft.com) PATCH tests are failing because data is submitted in a different format

Question

Hello, I'm working on implementing SCIM endpoints with Microsoft Entra ID, and am trying to use the validation tool at https://scimvalidator.microsoft.comto test the implementation. I noticed that all of the test cases which submit requests to the PATCH endpoint to update a User are failing, because the data is coming through in an unexpected format. Namely, the structure of the Operations Objects is different from what is shown in the documentation.

For example, when I click on one of the failing PATCH test cases to see more details, I see the body of the request looks like this:

{
  "Operations": [
    {
      "op": "replace",
      "value": {
        "name.givenName": "Oswaldo",
        "name.familyName": "Rylan"
	}
  ],
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ]
}

Both attributes being updated (name.givenName, name.familyName) are nested inside a single value of the one Operation object. However, per the documentation on developing SCIM endpoints, there should be an Operation object for each attribute, and each should have a path and value field. e.g. my understanding is that the request should look like this:

{
  "Operations": [
    {
      "op": "replace", 
      "path": "name.givenName",
      "value": "Oswaldo",
    },
    {
      "op": "replace",
      "path": "name.familyName",
      "value": "Rylan"
    }
  ],
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ]
}

Additionally, when I test my endpoints using a full end-to-end integration with Microsoft Entra Enterprise Application, I have verified that PATCH requests take that same format (one Operation per attribute), and so I built my endpoint to expect that data format.

So my question is this: is the validation tool sending data in an incorrect format? Because it is inconsistent with the documentation and what I have seen in practice with full end-to-end testing. Or is it a requirement that my endpoint needs to support both of these data formats? I haven't see that mentioned anywhere in the documentation, so that would be frustrating to learn at this point in the implementation process.

Answer 1

Hi @Test Admin ,

Thanks for reaching out.

Your understanding is correct, and schema of Patch request provided in the documentation is also correct.

However, as per RFC7644 , The "path" attribute value is a String containing an attribute path describing the target of the operation. The "path" attribute is OPTIONAL for "add" and "replace" and is REQUIRED for "remove" operations.

Thats the reason validation tool is sending data without path for replace operation

Hope this will help you to update your endpoint to accept both formats.

Thanks,

Shweta

Please remember to "Accept Answer" if answer helped you.