Why We Removed Nested Groups

The inheritance we got from Active Directory

The pattern comes straight from the Active Directory world, where nesting groups inside groups has been standard practice for decades. Teams that grew up on AD reach for it by instinct: put users in a team group, put team groups inside a department group, grant the department group access, and let it flow downhill. It feels tidy, and it is how a generation of administrators learned to model an organization in software.

So when people set up a new identity system, nested groups are one of the first things they look for. It is familiar, and familiarity is comfortable. But a pattern being familiar is not the same as it being safe.

Configuring them well is a skill, not a default

Doing nesting well is a specialized skill. Deciding what belongs inside what, avoiding cycles, keeping the depth shallow enough to reason about, and recording why each layer exists — that is real expertise, and it usually lives in one or two people on a team. Most organizations, especially smaller ones, do not have an identity administrator who has done it before.

That is what makes it a foot-gun. The happy path looks simple: a few groups, a couple of levels, access that flows. It is easy to set up something that works today and becomes unexplainable a year later, after a dozen more groups and a few reorganizations. The tool does not stop you; it just quietly lets the complexity grow.

The membership you cannot see

Nesting also hides membership. When a user’s access arrives through three or four layers of group-inside-group, their effective membership is no longer something you can look at — it is something you have to compute. Look at a person and you cannot say why they have access. Look at a group and you cannot easily say everyone it ultimately contains.

The association between a human and a privilege becomes indirect, and indirect associations are exactly the ones that outlive their reason for existing. Nobody removes a nested path they cannot see, so access accumulates in the dark.

Tie privileges to those groups, and permissions become a forest

It gets worse once privileges hang off the groups themselves. Grant a role to a group, nest that group a few levels deep, and the same privilege can now reach a user through several different paths at once. Removing access turns into guesswork: pull someone from one group and they may still hold the permission through another branch.

An audit question as basic as “who can do this, and why?” no longer has a clean answer — it has a tree you have to walk. That is how group-based privilege becomes a forest of permissions no human can hold in their head, and it is the quiet source of a surprising share of over-permissioned accounts.

What we do instead

So we made a different choice. In WebFrolic, only users are members of a group — groups do not nest. Permissions live on roles, and a role is always assigned for a specific resource instance, to a user or to a group. A group can hold several roles on one resource instance, or different roles on different ones, but there is no global, blanket mapping of privilege onto a group, and no chain of groups to trace through.

Where you do want membership to drive access, an automation rule runs when someone joins or leaves a group and assigns them a role as an explicit, visible step. Every grant names the resource instance it applies to, so who-can-do-what stays something you can read, instead of something you have to reconstruct.

We shipped it, then removed it

We did not arrive here from theory. We actually built group nesting — group-as-member-of-group, and roles attached to groups — and kept it behind a feature flag while we lived with it. It preserved the familiar AD model, which was the whole appeal.

But the longer we used it, the clearer it got that it was a foot-gun: it optimized for how people were used to working, at the cost of the one thing identity most needs, which is visibility. So we removed it altogether. Keeping it as an option would have meant shipping a feature we would then advise people not to turn on.

The trade-off is real — we gave up a pattern people know for one that keeps the permission picture legible. For a system whose entire job is to answer “who can do what,” we think that is the right trade. More on the model in how groups work and identity debt.