Hi, it turns out sorting in the case of LDAP is problematic:
- According to our expert there is no ready-to-use solution to perform LDAP server side sort, however there exists something called "virtual list view" (VLV) control that in theory helps obtaining consistently sorted results across requests
- OpenDJ supports VLV controls and they were tried in Gluu several years ago. In practice this led to big performance issues (server overload). It also required admins to prepare the search indexes beforehand. However in the case of SCIM, LDAP filters are dynamic and the sorting attribute is also variable so it's not a good match
- The above led to retiring VLV usage in SCIM and we resorted to perform a lax sorting in the service implementation.
Currently, a search with "sortBy" retrieves `count` elements using `startIndex` as offset, then the given page is sorted, not the whole result set. That is, we don't retrieve all user entries matching the criteria, sort them and retrieve the required slice. This is to avoid potential bottlenecks.
The above explains why you don't observe an absolute sorting but a local one. Unlike other backends (SQL, couchbase, etc.), LDAP does not seem to be a good fit for dynamic sorting.
We apologize these facts are not presented in SCIM documentation.
As a way to workaround it I wonder if you could increase the value of `count` in your app so that all potential results come in a single request... or trying to minimize the number of results by requiring tighter filters. This is of course, as long as the perceived response time is not heavily impacted.
Please account there is a `MAX_COUNT` parameter which can be set in oxTrust. This is in case you want to set `count` to high value. Actually when `count` is omitted, `MAX_COUNT` takes its place.