Bitwarden_rs: Implement poor man's invitation-only registration

Created on 12 Jun 2018  路  10Comments  路  Source: dani-garcia/bitwarden_rs

In current state one can either enable or disable user registration. I think it should be possible to implement some exception to the rule:

Admin and Owner of the Organization should be able to invite users not currently registered. For these special record would be made (possibly in a separate table?) that would allow registration of an user with specified email even if the registration is otherwise turned off. That way admin could turn off the self-registration, but he could still invite users if needed without having to restart Bitwarden to enable/disable it as it is implemented right now.

I'm not sure if I understand the invitation process on the client side properly, but I think it shouldn't clash with how it works right now.

Any thoughts?

enhancement

Most helpful comment

This is now implemented and documented in #173. The docker image with latest code should be built in next two hours.

@ViViDboarder I did the implementation also with your use case in mind, I think you should be able to implement your LDAP sync script. The idea is that you fetch email addresses of all your LDAP users and for those that aren't already registered (in the users table) you can insert the email into invitations table. That way said email address can register even with SIGNUPS_ALLOWED set to false. If you get around to doing that, I'd be interested in your setup, this is something we could add to documentation.

All 10 comments

I thought about a similar solution to yours some time ago. The problem is that we don't validate emails at all, so anyone that knows the email of the invited user could register an account first.
I guess the danger of that would be pretty low, knowing the user needs to be confirmed by an admin o owner to have access to the organization, so I'm okay with implementing this as long as there is a way to disable it.

Your idea seems alright, we would need to create a table for the invites (with email, organization id, user type, and collections the user can access) and basically delay the creation of the userorganization until the user is created. The problem with this is the invites would not appear on the organization user list, because that only shows userorganization and those don't exist for the invited users yet. We could change it so it shows both the userorganization and the invites but that seems like a hack.

Another option would be to pre-create the user and mark it as disabled until the user registers and the admin confirms the invite, which to me seems like the best option, but we don't have a disabled flag in the users table and I don't feel like doing an entire migration for that (maybe we can assume that if the masterPasswordHash field is empty that means the user is disabled or something).

Quick question, how does one disable user registration? I don't see that option in the Readme.

Just set SIGNUPS_ALLOWED environment variable to false.

Apologies, missclicked close.

What @mprasil said is correct. You can also modify the .env file if you prefer. I've added a short explanation of configuration options to the README in the last commit.

I would love that feature as well, but two things would mitigate the problem in a different fashion for me and might be easier:

  • Either have an option to send a notification mail to a defined admin address every time a user registers
  • Or have an option with an array of email domains allowed (my couple users would come from two domains only.)

Thanks for your work guys!

I like the second option, however there's a caveat that the email address is not verified in any way, so if someone figures out which domain is allowed he can still create basically infinite number of accounts.

I'd imagine, that in many cases this would be okay, but in many other cases it would be easy to guess the domain - like when the domain is well known email provider (gmail for example) or if the domain is same as where your BW server is hosted. It's kind of security by obscurity, but the truth is that it could be easy to implement and often good enough.

I would say have an array of emails OR email domains.

So I could specify gmail.com or just [email protected]

The idea of creating "disabled" users without a master pw is pretty good. It's a little opaque, but it's easy enough to understand.

This would also make it easier to implement something like LDAP syncing where users can be created automatically and they can set their master pass on first login.

This is now implemented and documented in #173. The docker image with latest code should be built in next two hours.

@ViViDboarder I did the implementation also with your use case in mind, I think you should be able to implement your LDAP sync script. The idea is that you fetch email addresses of all your LDAP users and for those that aren't already registered (in the users table) you can insert the email into invitations table. That way said email address can register even with SIGNUPS_ALLOWED set to false. If you get around to doing that, I'd be interested in your setup, this is something we could add to documentation.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

durd picture durd  路  3Comments

xhalo32 picture xhalo32  路  5Comments

mprasil picture mprasil  路  4Comments

djmattyg007 picture djmattyg007  路  5Comments

ghost picture ghost  路  6Comments