Introducing the new “Folders” feature

This article will give you a quick overview of this new feature exclusive to Passbolt. But before we dig into the details, here is a sneak peak in video.

Passbolt product vision has always been to combine the ease of use of a personal password manager with the flexibility of collaborative experience. This is one of the reasons support for groups has been added to the product quite early on, and is available for free to all users. Later, tags (labels) were added to help professionals in larger organizations manage passwords using another dimension. But these earlier versions of passbolt still lacked the ability to create more complex structures, such as a nested (or inherited) set of permissions.

Saying goodbye to shared vaults

It is worth noting that most of the other password managers also suffer from such limitations. Most of them use a system called shared vault (or collections), i.e. an archive that is symmetrically encrypted with a common shared encryption key, for a list of users (and/or groups of users). Inside this archive, all of the items can be accessed by everyone. And worse, the key is never rotated, even when a user access is revoked.

Similarly, most of the time, subfolders contained in such vaults do not carry over permissions, or rely on the client to enforce them. It is not possible to redefine permissions at an individual item or subfolder level.

We wanted to create something different and provide more control. The solution implemented in passbolt reuses concepts we are all used to. It borrows metaphors present both on a shared drive solution and in personal password managers like Keepass. Moreover it also leverages the encryption scheme and granular permission system that has always been one of the strengths of passbolt.

Settling for such a radically different design brought a few new challenges.

The design challenge

One of our early conclusions is that there is no “right way to share passwords”. Some organizations will set up themselves around projects and company departments. Larger ones might settle for a more complex organizational chart with more dimensions. Some users might just ignore all of this and just use the search bar.

We wanted to design a system so that each organization can define on the fly the model they want to use. There were a few of the hard questions that hit us while looking at the drawing board:

How do we design a system that helps enforce a structure but remains flexible enough? Or put it simply: how can it both enforce permissions while still allowing exceptions, e.g. extending and restricting rights at different levels ?

Approach for shared and personal folders

The easiest approach would be to enforce one big static tree structure for everybody and restrict the tree organization to a few decision makers. We believe this top down approach will be hard to digest for most users. If you ever tried to build a shared taxonomy within a medium or large organization, you will probably agree with us that this is not an easy feat. Moreover if as a user you only use sections of this tree, it is very likely that this structure will make even less sense or will slow you down.

So how do you represent information when you instead embrace a more flexible, personalized approach where not everyone is forced to follow the same structure? We have decided that Passbolt should allow collaboration at the intersection of what two or more users can see, while still maintaining users’ individual control on items that are not shared.

In practice this means that passbolt allows an item, a password or a folder, to be present in only one folder at a time for a given user. This also means that an item can be in two different folders for two different users, but only as long as these users cannot view both these folders. In other words, an item can be in several folders for many users at a given time, but there can only be one shared representation.

Similarly an item could be in two different shared folders, for two different groups of users that don’t overlap, letting each of these groups to construct their own shared understanding. Moreover it still allows an organization to enforce a top down structure if they want to, by making a “main tree” visible to everybody.

This approach creates a new interesting set of technical challenges (like detecting and resolving cycles), but ultimately it provides the most flexibility. We will explain how we solved these problems in separate posts for you, graph theory geeks. Spoiler alert: we rely on tarjan’s strongly connected components algorithm and some home-brewed heuristics to make decisions on what representation to keep.

Approach for nested permissions

Another challenge lies in how we allow associating permissions with nested folders and making it intelligible for the users. Like we said before, we wanted the system to be flexible, so this ruled out simple options such as having an administrator defining a set of frozen permission coming from top to bottom. That would restrict the user’s ability to interact easily with the enclosed items, so it should be possible, it should not be the default.

So, how do we allow creating a set of permissions in the parent directory that is applied to the items enclosed in it, but not set in stone? What happens when we move the folder to another folder with another set of permissions?

One of the key requirements is to be able to apply a given folder permission to the items inside it. For example when a user “share” a folder or create a new item in that folder, or drop an existing resource in a folder, the folder permissions will be applied to the items where possible.

The “where possible” is important here. While folders in passbolt can be used to organize resources and apply permissions, folders do not enforce the permission on its enclosed content at all times, but instead serve as a guide when an operation such as create or move is performed.

As we can see in the diagram above, exceptions can be created, i.e. it is possible for a user to have more access rights on a child item than they have on its parent folder. The opposite is also possible by restricting access rights, the same way it is possible to create a hidden or restricted file in a shared folder in a traditional filesystem.

Applying permissions on a folder is the equivalent of selecting all the resources the user has the right to share inside the given folder (is owner permission) and apply a new set of permissions to this selection. Items where the user does not have access to (or cannot edit the permissions) will be ignored.

This approach offers multiple benefits, but the most important is that it is easy to understand where the permissions are coming from. There will be only one source of permissions: the item itself. When creating an item, the parent permissions will be included in the children permission list, unless more are added or removed later.

It supports most complex use cases, such as creating a folder tree where the user will both be increasing and restricting permissions down the tree. It is possible to add a group or person to a folder permission mask, and therefore apply the permission mask to resources inside this folder, and then remove access to a person that is present in the permission mask or add a person that is not present in the permission mask.

The meaning of folder permissions

Behind the scenes, permissions for folders reuses the same permissions system currently available for passwords. This allows the user to associate a set of permissions to one or more folders, while reusing the metaphors the users are already accustomed to.

Like resources, a folder must have an owner permission defined in the folder permissions. Two other permissions types are available: update and read. Each permission type give access to operations as described in the grid below:

Once an item is inside a folder what can be done with the items does not depend on the folder permission but on the item itself, like on a regular file system. For a user to move an item that is inside a folder they must generally at least have update rights on the item and the destination folder.

Approach for permissions changes

So if there is no direct inheritance, how do we decide what permissions should be added and removed on a move? It’s simple, if you move a personal folder inside a shared folder, the permissions of the destination folder will be applied to a personal folder and the items inside it. If you move a shared folder to another shared folder, passbolt will look for permissions that are also present in the parent, remove them, and apply the new set of permissions from the destination folder.

This is the general rule of thumb, of course there are some exceptions, for example if you move a shared folder inside a personal folder, the permissions will not change. It is also possible for the user to decide if a given move should not affect the permissions, thanks to a contextual menu that will open if the permissions are about the change.

Wrapping up

We know that all this information might be a lot to wrap your head around! But we hope that you will enjoy using this new feature and that it will feel intuitive, as it was designed to stay out of your way.

While this feature is currently reserved for Passbolt Pro Edition and Cloud subscribers we hope to make it more generally available in the future. In the meantime if you would like to give it a try as part of a free Passbolt Pro trial, you can reach out to us at [email protected].

Thank you to all the users from the community forum that provided feedback on the specifications and took some time to test the release candidate, in order to iron out the last kinks. It means a lot to us!

Icon credits: Freepik.