Description

At present, subgroup lookups are not done directly through the storage layer by utilizing the GroupLookupProvider, GroupProvider, and corresponding implementations (e.g. JpaRealmProvider) and are instead supported on the GroupModel object only.

By expanding the storage layer's ability to interact with, lookup, and paginate results for subgroups, the door is opened to make tangible improvements to performance on the backend at scale. Notably, the ability to limit the amount of subgroups that are returned from the database and then loaded into memory

This eliminates the need to discard groups from the stream later as seen here:

as well as the amount of subgroups that are then consequently returned to the client at once.

Discussion

No response

Motivation

Red Hat is running into scenarios where groups operating at scale is becoming necessary (future multi-tenancy efforts being one scenario). Additionally, issues have been popping up from time to time where scalability is becoming an issue. Groups is one place that we have identified but could be used in the future as a template for how to ensure other keycloak resources scale well

Details

Some work has been done here but needs final touches, squashing, and a PR