This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Support for nested groups in DefaultLdapAuthoritiesPopulatorPage Title Module

Support for nested groups in DefaultLdapAuthoritiesPopulator

May 27th, 2008, 03:43 AM

The current implementation of DefaultLdapAuthoritiesPopulator supports resolving roles from the direct membership of the user in "role" groups.

I miss, however, the ability to support nested groups, i.e. where the user is member of a group (not necessarily a "role" group), which is then a member of a "role" group. This would make the administration of role groups much easier.

Large organisations typically have an established group-membership structure, based on organisational and security structures, and these groups are typically nested several levels deep, for ease of maintenance.

I realize that resolving nested groups would require additional search(es) in the LDAP, and that the implementing class, would likely have to turn DefaultLdapAuthoritiesPopulator search "on its head". The resolving process could take its start, resolving all "role" groups (i.e. groups rooted in one of the designated "role" roots), and then resolving the members, expanding any references to other groups (globally in the directory). This may require quite a few LDAP searches, and should therefore be cached, with an appropriate expiry (typically minutes), after which the role-groups are re-resolved.

Once a user is authenticated, the authorisation can thus be easily done against the fully resolved "role" groups, by performing a search of the resolved groups using the user's DN.

Have anyone successfully implemented support for nested groups, and if so, how did you implement it?

If not, do anyone have an easier (quicker) way of resolving nested groups than the process I have described above?

Comment

Hierarchical Roles means that roles may implicitly include other roles. This is implemented, released and documented, see jira.springframework.org item SEC-232

Nested Groups, however, seems not to be supported. So if a "role" group includes a user indirectly via another group (as one of its members), this role will currently NOT be assigned to the user.

It seems that, for Active Directory implementations, it is not necessary to recursively scan member groups, but a computed "tokenGroups" attribute on the user object includes references (via a binary SID) to all member groups (directly and indirectly referenced), for details. Several implementations exist for this. Search Google for "ldap active.directory nested.groups java sid"