Introduce account ownership (user access restricted to own accounts)

[lucab]

I was recently looking into having a multi-user setup of secmonkey, and saw that DB was designed with that usecase in mind, but some logic is missing in the backend. I now have a half-working PoC, and suddenly realized that the association table (linking account<->user) is never populated.

Before continuing, is there a rationale for this situation? Did you change your mind at some point (and why)? Also, after finishing the implementation, I suspect the migration step will be painful as it needs to assign all accounts to all users...

[scriptsrc]

Hey @lucab,

We are running a multi-user setup and it has been setup that way from the beginning. By a "multi-user setup", I mean that multiple users can login and see the same data in security_monkey. Is that the same thing you are thinking of?

I suspect that when you say "multi-user setup", you mean something quite different, like the ability to host security_monkey as a service and have different users monitor their own accounts, but without being able to see or modify accounts they do not own. Is my assumption correct? What sort of logic do you believe is missing?

I believe the association table mapping users and accounts is there to keep track of which users care about notifications on a given account. I probably meant to create a one-to-many relationship here instead of the current many-to-many relationship.

https://github.com/Netflix/security_monkey/blob/master/security_monkey/views/user_settings.py#L179 https://github.com/Netflix/security_monkey/search?utf8=%E2%9C%93&q=association_table

It will be empty until you go into Settings and subscribe to an account's notifications.

[lucab]

I suspect that when you say "multi-user setup", you mean something quite different, like the ability to host security_monkey as a service and have different users monitor their own accounts, but without being able to see or modify accounts they do not own. Is my assumption correct?

Correct. Usecase I've been recently asked: let some specific user administer/get notified/justify issues on some specific accounts, without having access to all the others.

Maybe describing it as "user segregation" or "account ownership" would be more correct, sorry for the mixup. Adjusting bug title.

What sort of logic do you believe is missing?

Some many-to-many relationship in DB to link account<->user, and filtering logic in python views to only return results for accounts the user can access. I have a work-in-progress lucab/wip/multi-user branch in my fork to explain the point better (beware: battlefield-quality code, hic sunt leones).

I believe the association table mapping users and accounts is there to keep track of which users care about notifications on a given account.

Ouch, it looks like I completely misunderstood the purpose of that table. I was expecting some kind of "ownership relationship" there.

[ollytheninja]

I think this would be better accomplished by having roles with access to certain accounts and then assigning those roles to different users.

[lucab]

I agree, it looks like it needs a completely different implementation.

Just for the sake of clarity, I'd call this "group membership" (where GroupA can access AccountA1, AccountA2, etc.) because in flask-security terminology "roles" already has a meaning (eg. roles like admin, read_only, can_modify_accounts, etc.)

[ollytheninja]

Sorry, I was referring to flask-security roles, I think they would work for this.