search

scimmyjs / scimmy

SCIM m(ade eas)y - SCIM 2.0 library for NodeJS
https://scimmyjs.github.io
MIT License
41 stars 10 forks source link

Attribute names are case sensitive #7

Closed winstonbond closed 11 months ago

winstonbond commented 2 years ago

Nice library. Thanks. I've been using it to build a simple SCIM demo app.

One problem: the filter matching works using a simple JS attribute lookup & compare (eg. return value[attr] === expected;), which means the attribute names are case sensitive. SCIM attribute names are meant to be case insensitive (RFC 7643, section 2.1 ... "Attribute names are case insensitive").

Unfortunately, the system I'm connecting to uses lower case names. It searches for 'username eq reddog123' and nothing comes back from the SCIMMY match function, because the attribute is called userName not username.

I guess the schema check would also fail if the ingress function got a JSON with unexpected cases for the attribute names.

sleelin commented 2 years ago

Hi Winston, thanks for the positive feedback! This does appear to be a bug in the filter matching logic which I will aim to resolve for release 1.0.0. Fortunately it only applies when using the built-in filter class to compare resources.

When creating/modifying/retrieving resources via the resource class's read/write/patch methods, they are always instantiated against the resource type's schema, and will use whichever casing was used in the schema definition (in this case, userName instead of username). This means that a client POSTing a user with "userName" or "username" will always result in a user resource instance with casing matching the schema ("userName" by default).

As the ingress/egress(/degress) methods of a resource are left up to you to implement in your ServiceProvider/client, the way you match resources is also flexible. Specifically speaking, when the ingress/egress method is called on resource read/write, the first argument is always the resource instance it was called on - which in this case would include a "filter" property that is an instance of the SCIMMY Filter class, which itself includes the property "expression" that is the raw filter expression string. This means that in cases where SCIMMY's filter matching functionality is lacking, it should be easy to temporarily substitute a more bespoke SCIM filtering package like scim2-parse-filter.

In any case, this is a bug I will aim to fix! I've implemented the spec as best I can, so if you run into any other issues please do let me know.

Thanks, Sam