Results of research
Members of dynamic groups are defined not via member attribute, but via memberURL, which contains the search query to list the group members.
Nevertheless, when we request the group via ldapsearch, it contains member attributes. E.g.:
The problem is that these member attributes are populated dynamically, which means that we can not use them in search queries directly. E.g. this query returns no results:
but in case of normal (not dynamic) groups it would have returned one group listed above.
As a result our LdapIdentityProviderSession#getGroupsOfUser does not work correctly. -> IdentityService#getCurrentAuthentication() contains no groups ever, which affects the behaviour of user/group dependent code.
- Customer can extend our Ldap plugin overriding at least LdapIdentityProviderSession#getGroupsOfUser method. (Further analysis needed to find out what other parts of plugin could be affected.) It seems that the specific customer - author of SUPPORT ticket - has group attribute defined for each user. In theory it can be used to search for user groups, but this is not a standardized approach -> does not make sense to be implement on our side.
- We could try to support dynamic groups in general. E.g. when useDynamicGroups configuration option is switched on, we avoid member attribute and rely only on memberURL defined for group. This though may have a bad impact on performance, as we would need to iterate over all groups and resolve the members list for each of them.
- We could extend our Ldap plugin by making search queries for "list of user groups" and "list of group users" configurable. This would be a more generic approach, but this is just a rough proposal. If we seriously considering to go this way, further research must be performed, before we promise smth.