New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Implementing RBAC #1333

Open
jordan-wright opened this Issue Dec 30, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@jordan-wright
Copy link
Collaborator

jordan-wright commented Dec 30, 2018

馃憢 Hi everyone!

I wanted to get some feedback on a proposal for implementing simple RBAC into Gophish.

To keep things simple, right now each user in Gophish is completely separate, and has all the same permissions. There鈥檚 no such thing as roles, or the ability to limit users from doing certain things.

This worked well enough so far. There鈥檚 been the occasional issue filed about wanting RBAC (including one from me!), but it鈥檚 never given us enough benefit to make it worth the effort compared to other features.

Now that Gophish is getting more mature, I think it鈥檚 time to reconsider adding RBAC- at least, to a limited extent. My goal is to start small and simple, only building out when we need to. To start, I want to create three roles:

  • Administrator
  • User
  • Viewer

Here's a little bit about the goals for each role and what we aim to accomplish.

Administrator Role

Right now, every user is pretty much an administrator. This works fine in smaller teams, but for enterprise users there may be a separation between the team that manages the Gophish infrastructure and the team that launches the phishing simulations.

The Administrator role aims to limit system-level administration to a smaller number of users. To start, this would include:

  • User management
  • URL management

I have to include URL management since URLs will need to be shared amongst all users due to needing consistent TLS settings.

User Role

The user role will be able to do everything an administrator can do, with the exception of managing other users or system-wide settings like URLs. They will be able to interact with objects like sending profiles, groups, etc., as well as launching and viewing the campaign output.

Viewer Role

The viewer role will be a read-only role. Users with this role will not be able to do any kind of system-management, or create/edit any objects. They will only be able to view objects and campaign information.

I'd love your feedback

This is a simple start, but hopefully it should hopefully take care of quite a few use cases while adding limited complexity. We can always expand this out later, but if anyone has feedback on this initial proposal, I'd love to hear your thoughts!

@jordan-wright jordan-wright added the rfc label Dec 30, 2018

@S0larflare

This comment has been minimized.

Copy link
Collaborator

S0larflare commented Jan 2, 2019

This is pretty much exactly as I would want it implimenting. I'd had a look at this a while back and I was considering having a crack at it (as there aren't that many direct mentions of the current user that you'd have to change to allow this to work), but this seems to be more comprehensive than my first attempt was going to be :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment