StreisandEffect / discussions

30 stars 3 forks source link

Feature request: User management / Access revocation #16

Open cpu opened 7 years ago

cpu commented 7 years ago

Suggested by @stevekuato in https://github.com/jlund/streisand/issues/235

I guess this is a question more than a feature request.

How would I go about revoking access to someone who I previously sent the HTML instructions to?

Is there a process for this? (e.g. regenerate the passwords + HTML file.)

Thanks.

aaronovz1 commented 7 years ago

I also think this would be a good feature to have. It would be nice if users could sign up for the VPN service and get unique credentials which can be revoked by admin or from expiration. Maybe to start there could be a script which can add/remove credentials from a list of servers?

yuna0x0 commented 6 years ago

Recommend to add this feature. Every user can get a unique credential which does not require to set up a new server and won't affect other users when revoking only a few users.

nopdotcom commented 6 years ago

Does every user have a username? Does the name have to be human generated? I prefer BIP names since they don't mean anything. (Like, users are named live.forum tiger.kick code.spider hold.mystery chalk.stereo easily.couch horse.meadow raise.please illegal.cereal law.naive. You can keep a table mapping bip names to human names, but in many cases you don't especially want that lying around on the streisand server.)

To what extent can we make credentials immutable? That is, old credentials just die, and users that come back from the dead get fresh credentials? This is connected to naming. If I want to re-use the username nop, that's a little harder than just handing me a fresh cert named number.unfold.

Is it worthwhile to partially complete this? Which protocols are most important? Can we tell people, "If you want credential management, you can't use Shadowsocks?"

What kind of live private keys do we need hanging around? New credentials need to be issued by a CA in some cases, so we need that.

Can user management be done from the command line? (Yes, I expect.) How about a web interface? (Probably not if I can avoid it; I like my webservers small and stupid.)

nopdotcom commented 6 years ago

Oh yeah, when I say "can management be done from the command line", there are actually two command lines: one on the builder where you run Ansible, and one on the Streisand server (the place where all the VPN stuff lives).

nopdotcom commented 6 years ago

Could there be a way of sucking down old credentials from a server, and pre-populating a fresh server with those credentials? That would make my life easier as a dev too; I have several live instances with users, and I wanna keep those servers up to date without handing everyone a new streisand.html.

aaronovz1 commented 6 years ago

You could use a randomly generated client/account number instead of usernames. If it is easier to just let it expire and have the user ask for another, I think that is fine. This is similar to how Mullvad works except users can reuse their account number.

DarthSlider commented 6 years ago

It should look like this: admin logs into the server and create a new straisand user. It should generate personal profiles, keys and manual pages for this user. After that, each user should log in to your server with they own username and password and get its own manual. It would be a super useful feature. Also makes revoke of access really easy.

nickolasclarke commented 6 years ago

@nopdotcom

Could there be a way of sucking down old credentials from a server, and pre-populating a fresh server with those credentials? That would make my life easier as a dev too; I have several live instances with users, and I wanna keep those servers up to date without handing everyone a new streisand.html.

this has been a pain point for me for a long time that I've made some silly hacks around. You hit it right on the head. I want to update to pull in new developments, but with creds passed around to very non-technical individuals scattered across the country, there is a lot of friction to do so.

Does every user have a username? Does the name have to be human generated? I prefer BIP names since they don't mean anything. (Like, users are named live.forum tiger.kick code.spider hold.mystery chalk.stereo easily.couch horse.meadow raise.please illegal.cereal law.naive. You can keep a table mapping bip names to human names, but in many cases you don't especially want that lying around on the streisand server.)

To what extent can we make credentials immutable? That is, old credentials just die, and users that come back from the dead get fresh credentials? This is connected to naming. If I want to re-use the username nop, that's a little harder than just handing me a fresh cert named number unfold.

I think that immutable, BIP names certainly make this easier to get off the ground and better protects for privacy concerns. +1 in my book to that approach.

GauthierPLM commented 5 years ago

The best way would be a CLI tool allowing to generate and revoke certificate for each tools, probably based on existing ansible tasks. A certificate management tool, which could also handle importing/exporting certificates from one server to another as well as listing available certificates with the associate credentials (similar to what is in the instruction files now).

Then, a simple optional web app could be used to interact with this CLI tool and display a dynamic portal to the server. Regarding credentials, I suggest using certificate name/password. Like that, if a certificate is revoked, the user is blocked too. The admin would be the one sending credentials and managing registration, so no mail/password/personal info is used.

I'd like to work on this, but I am not familiar enough with the tasks available and the changes needed in Ansible tasks to allow this.