I’m currently working on an import tool for importing data from a password manager currently not supported by Bitwarden. This password manager uses a hierarchical data structure with unlimited depth.
What would be the best import behaviour for converting these hierarchical structures into the Bitwarden eco system? I thought about creating collections for every folder of the old password manager and then assigning the actual password entry to all collections which have been folders in the breadcrumb leading to that entry.
Doesn’t look nice tho in the end, because the entry is shown for every of these collections and not just the last one at the end. But since Bitwarden has no way to handle this, I can’t think off anything better.
Any ideas? Was anybody able to import hierarchical password structures into Bitwarden in a better way?
Thanks for any hints on this!
Could you describe this in more detail, for those of us not familiar with Password Depot or other “hierarchical password managers”?
Is there a reason why you couldn’t use nested folders, which are supported in Bitwarden?
I’m assuming company usage of the password manager, which is the case in most scenarios I came across, including our own use case. For that, we used a password manager which organizes the passwords in a hierarchichal structure with no depth limitations. The root of every branch can be assigned to access rights for groups or individuals.
This common scenario is not possible with Bitwarden as far as I know. One would assume, that creating a collection with access rights and then putting nested folders in it would solve this. But collections can’t have folders.
Using folders only wouldn’t work as well, because:
“Folders organize your individual vault and are unique to you, where collections are shared between members of organizations.”
Collections only wouldn’t work as well, because they don’t inherit access rights from their parent collection, which is hilarious if you have a collection of hundreds if not thousend of credentials in a medium sized company like ours and cannot be used sensibly in practice.
Since I can’t come up with any other ideas, I 'd like to ask here what the best practice for business users is. I’m sure there must be one, else Bitwarden wouldn’t be successful the way it is. I’ve probably just overlooked it so far.
Another reason for asking is the convertion tool from our old password manager to Bitwarden I’d like to publish. It’s already working, but it’s creating nested collections right now, which is not a good solution due to the missing access right inheritance. It’s working more like tags.
Hierarchical structures are represented as folders on individual vaults and collections on organizational vaults. Nesting is possible, but only within on or the other (folder → subFolders / collection → subCollection).
I agree that currently there’s no good way through the UI to setup permission inheritance for nested collections. This is currently with a script that the integration team built.
Usually an owner or admin takes care of the migration and then starts to setup users/permissions within Bitwarden. There’s also another case where the admin/owner sets up dedicated collections with appropriate permissions and then lets users import their data into them.
For the sake of the import it really shouldn’t matter though as almost all systems I’ve migrated don’t provide any user or permission data within their exports. A dedicated import tool, using apis from the system to be migrated is possible, but way more involved than the current path to import handles.
Having a look at some of the current importers that support folders/collections, they usually start out by calling processFolder which is just a method that takes care of creating the hierarchy based on import file. In case the user is importing into an organization, those folders and folderRelationships are then converted into collection and collectionRelationships.
I hope that clarifies some things, but feel free to comment or message me again, if you need further info.
Kind regards,
Daniel
Thanks for your clarification. I agree that access rights are usually not exported by password managers. In case of Password Depot it’s not that important, because there is a main container (root collection if you like) which is holding access rights. Everything inside that container (folders, entries) has the same access rights. And that is something that I really miss with Bitwarden. It’s not possible to organize stuff in a neat way without having a huge workload on setting permissions for every child collection beyond the root collection individually. I think this is indeed a design flaw, at least for organizational vaults.
There is a script available (from Customer Support), which will automate this process.
Thank you, I didn’t know that. That’ll help us a lot during migration. The script is actually publicly available in the corresponding Github repo, no need to contact customer support.
Thanks for posting the link. However, I note that the “bitwarden-labs” repo is not Bitwarden’s official repo, and its README has a disclaimer stating that its contents are “not officially supported by Bitwarden”. On the other hand, some (but not all) of the contributors to that repo are Bitwarden devs, and your comment just received a 
reaction from @djsmith85 — so it is probably safe to use…
The official Bitwarden customer support handed the link to me without any further notice that it’s 3rd party. So I assume as well that it’s safe to use.