For a SMB, I’m trying to PoC a workflow ; I’ve activated ORG_GROUPS_ENABLED and I’m using the Bitwarden Directory Connector to synchronize my groups/users from Azure Directory; so far so good.
For the organization of shares, I imagined a Collection per Group (with the appropriate access) and it’s fine to share a Secret for a whole Group.
Here, the Finance department has three shared secrets in the team, and Alice, Bob and Charlie can all access them :
.
├── COM
├── DEV
└── FIN
├── secret1
├── secret2
└── secret3
But I don’t see how I can enable finer sharing: if user Alice wants to share a Secret with Bob (and only him) it would require a Collection with Alice and Bob in access, say Alice-Bob ; but I can’t imagine creating a Collection by pair, with 5 people it would be Alice-Bob, Alice-Charlie, Alice-Daniel, Alice-Eve, Bob-Charlie, Bob-Daniel, Bob-Eve, Charlie-Daniel, Charlie-Eve and Daniel-Eve, pfew. Let’s not talk about three-person shares, or shares between people from different departments…
What secrets do you think should be shared between two people in the organization vault? I mean if Alice wants to temporarily share a secret she could always use a Send link for that (or wait until individual vault item sharing is implemented).
Well, the « Vault Item Sharing » topic has a ton of scenarios and reasons why this won’t work.
We just don’t always share everything with everyone. And we have plenty of secrets that would be worth sharing with a specific subset of users, for reasons that are beyond any business/position considerations. Here’s a that-s-how-real-life-goes example: we may want to share the Printer Admin password with two users, just because they sit next to the printers. Groups/position are not involved at all here. I could create a PrinterPowerUsers Collection, which falls into the One Collection Per Need problem.
As for the Send function, it may work for sharing a Secret temporarily only:
Send is just a Poor Man’s encrypted messenger, it is not a share
This (poorly) works until the sent Secret is modified by it’s owner
It doesn’t handle the TOTP share
Plus, it is absolutely not userfriendly… Quoting some reply, the process is as such:
Copy password from vault
Click Send tab
Click new Send
Select “Text” option
Paste in password
Save Send
Click Send options
Click copy Send link
Paste Send into email client
What a journey! There is not a single chance my users would do that (to be honest, it is painful enough I would not do that myself). Chances are they would take a picture of the secret (TOTP included) and send this by mail or any other insecure mean.
But thank you very much for pointing me at this thread! It does give a lot of answers - just not the ones I was expecting
everyone been wondering the same… since 7 years
the Item Sharing feature is apparently not near to be released
plenty of workaround attempts were described, along with their limitations, so I won’t loose my time trying those
I felt like I was missing something obvious, but it seems that it was in the code that something was missing.
While I was wondering (too much), Pull Request 5488 was merged ; it restores the ability of the Manager/Custom role to create Collections within the Collections to which it has access.
So my initial plan was indeed feasible! I can create my FIN COM DEV Collections/Groups, and within each Group, give this role to a Power User. This Manager will be in charge of creating Collections and establishing the Accesses required for fine-grained sharing within his Group.
Of course, direct sharing of a single Secret from one user to another remains a feature I’d like to see, but that’s another subject.
