Comparison filters do not support case-insensitive matching

[BrandonGoddard-at]

I believe there is an issue where comparison filters on string type attributes do not support case insensitive matching. I think this should be supported based on reading
https://datatracker.ietf.org/doc/html/rfc7643#section-7

caseExact  A Boolean value that specifies whether or not a string
         attribute is case sensitive.  The server SHALL use case
         sensitivity when evaluating filters.  For attributes that are
         case exact, the server SHALL preserve case for any value
         submitted.  If the attribute is case insensitive, the server
         MAY alter case for a submitted value.  Case sensitivity also
         impacts how attribute values MAY be compared against filter
         values (see [Section 3.4.2.2 of [RFC7644]](https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2.2)).

and
https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2.2

When comparing attributes of type String, the case sensitivity for
   String type attributes SHALL be determined by the attribute's
   "caseExact" characteristic (see [Section 2.2 of [RFC7643]](https://datatracker.ietf.org/doc/html/rfc7643#section-2.2)).

i.e. a filter of displayName eq \"TestGroup\" should match testGroup and TestGROUP, etc.

I ran into this issue when trying to get an Azure AD app approved, and it looks like this is their interpretation of the spec as well

[thomaspoignant]

Hey @BrandonGoddard-at thanks for reporting this issue, I've reread the RFC and, I think you're right this should be case insensitive.
Do you know if Azure AD is using the caseExact field?

Do you mind looking at the issue and opening a pull request for this?

[BrandonGoddard-at]

Do you know if Azure AD is using the caseExact field?

Yes, at least for the standard cases in the core schema (i.e. group name filters). I've got a pretty blunt patch that we applied since all of our string fields we cared about were case insensitive. It looks something like this:

class CaseInsensitiveFilterTester extends Tester {
    override attrTest(path: Array<string>, r: any, op: (r: any) => boolean): boolean {
        if (path.length === 0) {
            return op(r?.toLocaleLowerCase() ?? r);
        }
        return super.attrTest(path, r, op);
    }
}

but If I have time I'll see if I can properly put up a PR that makes this an option on filter()

[thomaspoignant]

but If I have time I'll see if I can properly put up a PR that makes this an option on filter()

it would be awesome 🤓

[duaribiju]

Hello,
Any update on this issue, I can see case-insensitive is still not supported in the latest version.

[thomaspoignant]

@duaribiju I had no time to work on it, and it seems that @BrandonGoddard-at had no time neither.

If you want to give it a try you are welcome.

[DillonSadofsky]

I was just going to report this same issue. I just had a client go live with MS Entra ID, what I believe used to be called Azure AD above, and we had a lot of issues with duplicates because our system was already live, so it attempted to match users up and that ended up creating duplicates I had to manually clean up. This was because it would go through the logic of:

1. attempt to match an Entra user to a service user based on externalId (won't match because we've never synched before)
2. attempt to look up a user using userName which in my /scim/Schema endpoint is displayed as:

        {
          "name": "userName",
          "type": "string",
          "multiValued": false,
          "description": "Unique identifier for the User, typically used by the user to directly authenticate to the service provider. Each User MUST include a non-empty userName value. This identifier MUST be unique across the service provider's entire set of Users. REQUIRED.",
          "required": true,
          "caseExact": false,
          "mutability": "readWrite",
          "returned": "default",
          "uniqueness": "server"
        }

(Note specifically the caseExact part, which I didn't change from the SCIM 2 default)
Let's say that Entra would try to find an existing user as John.Doe but we had a John.doe. scim2-parse-filter would do a case sensitive search due to using javascript === operator locally and no rows would be found.
3. Since no row was found, this user would be considered 'new' and would be provisioned new as John.Doe which, due to the case insensitive but unique nature of userName, would collide, leading to an error, which would essentially get them stuck in an infinite loop. This was annoying.

So personally, I see this as a critical issue. In my opinion, without this change, this library is probably only being used by people who provision only on 'fresh' systems, where users are provisioned by the identity management service, and never have to 'match up' existing users that may pre-exist.

So, how to solve the issue? In my opinion, the minimum viable solution would be to switch all comparisons in this library to case insensitive compare (do tolower to both sides beforehand or whatever). I think there are very few attributes where the user would be upset that they searched for "test" and they found a result "TEST" and they are confused.

I think the "PROPER" (but much more complicated) solution would be to somehow be able to check the /scim/Schema payload and per attribute, base case sensitivity on that. The architecture of this library isn't currently set up for that though, so I'm not asking for that. I think making all comparisons case insensitive would be the better default and (in my opinion) won't really disrupt any current users.

Previous comments suggested making it an argument on filter, and although that would be powerful, I think its blocking progress on this which is pretty critical and I doubt anyone really wants to toggle it off/on per field. I think generally URLs (where these filters are encoded) are generally treated as case insensitive. So in my opinion, this is a single, global preference, and barring any other good argument to the contrary, this library should not take case into account.