Uppercased boolean breaks patchrequest filter

[willemvermeer]

Hello, I am trying to connect a Microsoft Azure datasource through the 3.2.0 scim2-sdk-common library.

A Microsoft patch request looks like:
{"op": "replace", "path": "roles[primary eq \"True\"].display", "value": "LLWNASSGATWP"}

which results in an exception:
Attribute roles does not have a value matching the filter primary eq \"True\"

when I change (manually) the filter from True by true it works fine.

Could it be an improvement in scim2-sck-common to lowercase the True-value when we know the filter is on a Boolean type? Should I look in Microsoft/Azure to change the way the filter is constructed? Or am I maybe missing something completely obvious here?

[kqarryzada]

Hi @willemvermeer. The SCIM specification states that attribute names (e.g., primary) and filter operators (e.g., eq) are explicitly case insensitive, but the same detail is not given to attribute values in filters. This is why the SCIM SDK's processing is strict about case sensitivity for this filter. It's also worth noting that the value in the filter is quoted, so it's searching for the string "True" value and not a boolean. Unfortunately, I don't think it's straightforward to rely on the schema in this case because the value is being provided as a string.

Azure's SCIM provisioner is known to send boolean values as uppercased strings, which has caused problems for SCIM clients in other areas before. I will look into whether there is a Jackson setting that would treat these values as case insensitive even if it makes the computation a bit more expensive.

[willemvermeer]

Thanks for the response @kqarryzada , sounds good!

[kqarryzada]

@willemvermeer, I've looked into this. Unfortunately, I was not able to find a Jackson setting that would address this use case. This is hard to accommodate because the value is sent as a string. I think this would require a code change, either via a workaround or within the SCIM SDK itself.

You could add some logic that takes PatchOperations and manually replaces them with new ones if the value is a "True" string. But this may be onerous.

It's not really feasible to use the schema here because the processing logic is at the parsing layer, which does not get visibility into the data type. This is because the parsing logic is initiated by Jackson when deserializing the object. Furthermore, a patch operation can be interpreted without knowledge of the schema. One idea I've explored is the possibility of a configuration option. You could give this a list of attribute names, and for filters with those attribute names, any string "true" or "false" value, regardless of case sensitivity, would be interpreted as a boolean instead. Would such a feature address the problem for you?