What's the extent to which filtering is supported?

[pablodiazgutierrez]

First of all, thank you for putting out this excellent library. We are so glad to have it around. We are using it to interact with Microsoft's AAD user provisioning system, and so far it has served us well.

Now, we've heard from Microsoft staff that they're adding some tests and that we're failing them. Specifically, they ask why when they query /Users?filter=userName+eq+"email@address.com" the result is blank (even though they can query /Users/USERID successfully for the same user).

I will point to them that, as explained in /ServiceProviderConfig, filtering is not supported. However, in the code it says that there's partial support. So I'm wondering:

• What's the extent of this support?

• How can we help extend this support to include the query above?

Edit: I should have labeled this issue a "question" or "help wanted", but I didn't see the option. Sorry!

[logston]

Wow! Thanks for the feedback! Great to hear it's helping someone :)

I work on this on Friday's at the moment (thus limited time) so it might take a while to get back in full but here is the gist:

• This library does support filter from a number of the major IdP/SCIM clients out there:
  • Okta
  • Microsoft Azure AD
  • Google GSuite
  • OneLogin

I think I added the comment so that I could under commit and over deliver. It's been several years now so I forget exactly.

As for the query, have you configured your AttrMap for the User model? For example:

    USER = {
        # (attribute, sub-attribute, schema): db field
        ('externalId', None, None): 'scim_external_id',
        ('userName', None, None): 'scim_username',
        ('name', 'formatted', None): None,
        ('name', 'familyName', None): 'last_name',
        ('familyName', None, None): 'last_name',
        ('name', 'givenName', None): 'first_name',
        ('givenName', None, None): 'first_name',
        ('displayName', None, None): None,
        ('emails', 'value', None): 'email',
        ('addresses', 'streetAddress', None): None,
        ('addresses', 'locality', None): None,
        ('addresses', 'region', None): None,
        ('addresses', 'postalCode', None): None,
        ('addresses', 'country', None): None,
        ('addresses', 'formatted', None): None,
        ('addresses', 'type', None): None,
        ('addresses', 'primary', None): None,
        ('title', None, None): 'title',
        ('active', None, None): 'is_active',
        ('preferredLanguage', None, None): None,
        # urn:ietf:params:scim:schemas:extension:enterprise:2.0:User
        ('employeeNumber', None, None): 'employee_id',
        ('employeeNumber', None, SchemaURI.ENTERPRISE_USER): 'employee_id',
        ('department', None, None): None,
        ('department', None, SchemaURI.ENTERPRISE_USER): None,
    }

When inheriting from and overriding the SCIMUser adapter in your own code, you can add a class level attribute that will point these queries at the right DB table fields. If this doesn't quickly solve your issue, let me know and I can take a look next Friday.

[pablodiazgutierrez]

Wow, thanks for the quick response and for the hints. I was able to find the root cause of our problem, although I'm not exactly sure about the solution. Let me explain a little bit.

Our service is a multi-tenant app. There is a concept of an Account that holds several Users. In order to isolate accounts from one another, so that a simple query to /Users doesn't return every single user in the system, we defined a get_extra_model_filter_kwargs_getter which returns {'userprofile__account__id': request.user.userprofile.account.id}, in practice something like {'userprofile__account__id': 1}.

This works well for generic queries, but looking at the search code, I see this in FilterMixin:

    def _filter_raw_queryset_with_extra_filter_kwargs(self, qs, extra_filter_kwargs):

        obj_list = []
        for obj in qs:
            add_obj = True
            for attr_name, attr_val in extra_filter_kwargs.items():
                if attr_name.endswith('__in'):
                    attr_name = attr_name.replace('__in', '')
                    if not hasattr(obj, attr_name) or getattr(obj, attr_name) not in attr_val:
                        add_obj = False
                        break

                else:
                    if not hasattr(obj, attr_name) or getattr(obj, attr_name) != attr_val:
                        add_obj = False
                        break

            if add_obj:
                obj_list.append(obj)

        return obj_list

The effect of the else block is that nested queries like the one we pass are not supported, and since userprofile__account__id is not an attribute of User, the result is that every result is thrown away. To confirm this, if I disable our get_extra_model_filter_kwargs_getter, then I can filter users properly. But now we're leaking all our users to anyone with access to the SCIM API.

Do you have a good suggestion for this? I suppose I could reimplement FilterMixin._filter_raw_queryset_with_extra_filter_kwargs, but I'm not sure why it's ignoring nested queries.

Thanks again for any input you may have! Hopefully this feedback also helps improve your terrific library.

[pablodiazgutierrez]

I spent some time and found a solution that works for me, in PR #48. Essentially, I process the nested field names and then compare the final value.

It's pretty self contained, but let me know if you'd like me to make any changes!

[pablodiazgutierrez]

We can close this, and keep any further discussion in #52 and related. Thanks @logston for your help!