The Issue with Updating Inherited Groups in AEM 6.2 Using the Classic User Admin Interface

If you still prefer to use the classic UI for user administration for whatever reason (easier to get to/shorter URL to type/whatever), then there’s a new "feature" to be aware of in AEM 6.2 which has to do with modifying groups to which users belong. As all AEM documentation suggests, the best way to maintain user access rights is by maintaining a carefully structured set of groups whose members are other groups (and/or users).

When you have a user belonging to a group which inherits from other groups, all the inherited group names get listed explicitly when viewing the groups to which a user belongs. This has the unfortunate consequence of updating everything that’s visible in the list upon save.

In order to illustrate this behavior, navigating to the Classic User Admin interface at http://localhost:4502/useradmin, I set up a semi-arbitrary structure of groups where each have their own specific increased or decreased permissions. The top level group, containing the least restrictive set of permissions, called content-admins inherits permissions from content-authors which inherits permissions from content-copiers which then inherits permissions from content-proofreaders. Each inherited group containing more restrictive permissions, respectively, as expected.


When I add a user to the content-admins group & then display the list of groups for that particular user, you’ll see not only the content-admins group, but all of the groups from which content-admins inherits as well.


The Content Authors group used in this example was the OOTB content-authors, which incidentally inherits from a few other groups- those groups also get itemized in this list.

This listing, however, is completely innocuous. You can verify that by taking a look at the Touch UI variant of the user administration interface (http://localhost:4502/libs/granite/security/content/useradmin.html)- and if you don't believe that interface, you can even take a look in the JCR & see the members of each group (listed by their UID) in the rep:members property (found at http://localhost:4502/crx/de/index.jsp#/home/groups).


Once you start updating the groups of that user in any way, the user will be added to each of the groups listed under his account. In this case, I added this user to an additional group. (Note: simply adding a group in the interface does nothing. Clicking the Save button triggers the writing to the JCR)


Once saved, this user was added to all of the groups in his list of groups. This can be verified by viewing the list of groups to which this user belongs in Touch UI, or going through each of the expected inherited groups in the JCR (& looking for the value of the aforementioned property, rep:members).
Finally- if, at some point, you wish to remove this user from the group to which he was originally added, all of the inherited groups will remain & have to be removed individually.

Please note, that this issue only occurs when managing groups in the user properties interface. If you strictly manage users from the groups' properties, that is- if you add/remove users in the group itself, then you will not experience this issue. (Or you can use the Touch UI for administration)

So, if you notice some weirdness with group membership in 6.2, user administration in the Classic UI may be the cause of it.

Source: http://www.6dglobal.com/blog/issue-with-updating-inherited-groups-in-aem-62-2016-08-12