“It’s a question of trust. It’s a question of not letting what we’ve built up crumble to dust.” – Depeche Mode, A Question of Lust
The answer to my groups dilemma struck me as soon as I began to implement the administrative functionality. We really have two fundamentally different groupings at play: people and things. I was trying to represent both with a single entity, but they’re fundamentally different.
People – Trust
A Trust represents a collection of people who place ultimate faith in a subset of administrators within it. Those admins get special powers such as maintaining the user listings. The can’t delete a user from the system completely (only a system administrator can do that), but they can remove someone from the trust, which will revoke the access to anything they’d gained from its groups.
Things – Group
A Group can then be created within a trust, or can stand alone. When a group is part of a trust, the administrators will automatically be given access to it, including administrators added later. Alternatively, groups can be privately shared between two users. Without a trust to control their access, these groups are static and their membership cannot be altered. While a secret can be shared between multiple groups, or even between multiple trusts, any user with access can see a full list of those groups, but cannot alter that membership unless they have he appropriate administrative access.
Again we go back to how much easier this would be with a monolithic vault system, but it’s an inherently flawed design. It might solve a lot of problems with access, but it encourages duplication, and that’s especially harmful when you’re dealing with passwords. Passwords should change regularly, and when you end up with a password stored in two places, one of them will soon end up out of date, which is worse than useless.