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!