dani-garcia / vaultwarden

Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs
GNU Affero General Public License v3.0
37.4k stars 1.82k forks source link

Support for groups #245

Closed ptman closed 5 years ago

ptman commented 5 years ago

https://help.bitwarden.com/article/groups/

dani-garcia commented 5 years ago

I'm not sure if I'm missing something, but I don't see any difference between this and organizations. Instead of having an organization with multiple groups, you can create multiple organizations, and it serves the same purpose, it seems.

For now I'll mark this as low priority, and if someone wants to help implement it, I'll merge it.

dani-garcia commented 5 years ago

To keep the issue tracker more focused, I'm closing this issue in favor of the meta issue at #246.

miko007 commented 5 years ago

this meta issue thing is kind of a stupid idea. i can not really focus on the "groups" discussion, because all topics are mixed up in issue #246.

group support is essential for the use of this implementation in organisations. has there been any progress been made on this topic?

the "multiple organisations" workaround has the major downside, that datasets can not be shared between organisation. one has to keep track of all the likewise entries in all organisations and keep them synchronized. i do not think, that this is of "low priority".

dani-garcia commented 5 years ago

There hasn't been any progress in the groups functionality and unless someone steps up to implement it there won't be any, as I have zero interest in implementing this.

If you need to share entries between organizations, create a new organization for all the users that need the shared entries. If your organization is so big that doing that becomes unworkable, you probably have enough resources to deploy the official server, and then you'll have your groups.

My vision of bitwarden_rs is focused on small to medium deployments, where the implementation of groups really is "low priority".

PD: In the future I'd refrain from calling things stupid, there is no need for that language here, we are all volunteering our time for free, you might not like our ideas, but as a minimum they deserve a little respect.

miko007 commented 5 years ago

Well, it seems you totally got me on the wrong foot there. First, i can not see in which relation calling an idea stupid stands to any form of respect for people. I just put out my opinion, and in that, the idea is stupid. Does not have anything to do with you, nor other people contributing to the project.

Next, our company, which has round about 25 employees has a "medium deployment", i think. We already have the official server deployed an we also pay for every single license. This is not the point here. I thought, i would bring some insights from your target audience to this open project.

And from an administrators point of view, i want to tell you, that groups are a feature, which is used quite often, and makes life so much easier.

We have for example interns, which only should be able to look at the "read-only" accounts. We have developers, which need to see all the administration datasets as well as the "read-only" ones, an so forth.

Splitting all this up into different organizations would mean, those datasets can not coexist inside the same collection, as collections are organization bound, and therefore would be difficult to find.

I hope, at least somebody can relate.

love and respect. Mike.

aiveras commented 5 years ago

We are also an SME and would need this feature. Especially in combination with LDAP group policies are necessary to scale a company. If you have to create a new organization for each group, it also complicates maintaining passwords. That's why I can only agree with @miko007 that this is a basic feature and has nothing to do with the size of a company or the willingness to buy. Especially in the sensitive area of passwords, a filigree identity management is almost equally weighted with the security of the password storage. After all, most leaks are not caused by technical errors but by people passing them on. For this reason, and I think every system administrator can confirm this, the lowest access rights are always granted in IT systems to protect data sovereignty.

ptman commented 5 years ago

While I agree, that organizations and collections make groups a nice-to-have instead of a must-have, groups are most likely very nice once you have enough users.

sangdrax8 commented 3 years ago

Ouch, I didn't realize groups were missing. This could actually strongly relate to issues implementing the ldap-connector support I was looking at. Pulling in groups from LDAP becomes a moot point if groups don't exist on the server side to sync them to.

lethargosapatheia commented 3 years ago

I'm not sure if I'm missing something, but I don't see any difference between this and organizations.

I find the statement a little bit bewildering. The point is, of course, to be able to add a group of users to a collection, instead of each individual user. What if you've got 50 people in one team and you want to share a collection with them? Instead of adding the group, you have to click 50 times, basically. Having 50 people in one team doesn't mean you're a huge company. Creating another yet organisation doesn't make any sense in so many cases and doesn't make things easier.

That you don't want to because you think there's too much effort to be made or don't have the time or whatever is understandable. That you think this is useless functionality for small/medium companies is quite disconcerting.

pepa65 commented 3 years ago

In our organization, we didn't see the need for organizations, and we thought it would be confusing to our users, so we called them "groups". But the functionality is actually not the same, and having groups to me is much more interesting that having organizations (even if they are called "groups"...).

BlackDex commented 3 years ago

Any well written PR would be welcome.