Comment 12 for bug 1555629

Consider the use cases for domain-specific backend, which is mainly designed for (read-only) LDAP integration for identities, it is unlikely that the operation of listing all users from all LDAP domains at once would yield pleasant user experience. This is the same logic we used to argue against pagination in the first place. So iterating through all the domains do list all users in one shot is not the way to go.

On the other hand, API consistency matters, even with proper documentation on the change of API behavior depending on backend configuration. We should NOT be forcing API users to code around different backend configurations when we don't even have a way for them to discover that information programmatically. Horizon is currently facing a similar issue, which is unable to discover whether Keystone is running with a read-only LDAP backend. Therefore, it doesn't know whether to grey-out the user create/update menu. This also result in poor user experience.

I can think of the following options:

1. always make user pass in the domain filter or get the domain filter from the token scope as user management should always required a domain-scoped token
2. return HTTP 501 not implemented if domain filter is absent
3. have a way for users to discover the API behavior