Midburn / spark

"burn in a box" suite of services that composes everything required to run a burn event throughout the year
Apache License 2.0
18 stars 46 forks source link

Better roles and permissions #586

Open amotenko opened 6 years ago

amotenko commented 6 years ago

Convenient and flexible mechanism for roles and permissions

See discussion here: https://github.com/Midburn/spark/issues/571

ArtyomKa commented 6 years ago

Right now we user roles defined on the users table level. The problem with this state is that the roles are defined without a context. Meaning if a User defined as an admin or a camp_manager, and it makes him an admin for all events and for camps or art installations that he/she associates with.

So my first step is to create a table to hold roles data in correct context - with event id and camp id see #594

ArtyomKa commented 6 years ago

A question here: We have departments managed in two places - spark and volunteers db. We should have it stored in one db and make this accessible via API

amotenko commented 6 years ago

Yes, roles should definitely have their own table, with event ID and I thought, let me know what you think, also with module ID. This way you can open permissions on module by module basis. (modules are not identical to departments, but may overlap sometimes).

Also for additional flexibility, a permission row can contain sub module, so for example an admin for camps in an admin, but a camp manager only controls his camp.

ghost commented 6 years ago

I agree. We should have an auth service, which any system can use and the JWT will include claims for all permissions across modules and across systems.

I did something very similar in Java a couple of months ago for work.

So all the user-related services will be done by a single service for anything Midburn, incl. sign up, roles, login, forgot password, etc Like an active directory for midburn users.

This will also spare us the SSO between Midburn systems development efforts.

I am willing to take this, but I’ll most likely need someone to give me a hand.

While we’re at it, I’d make the authorization process a little cleaner.

It drives me insane that every 10th line is “user.isAdmin” or “user.isManager” If he isn’t an admin, he shouldn’t have reached this code. He should have been rejected by the component verifying the JWT (I think passport can do this...) It will make the code much cleaner IMHO

On 27 Jan 2018, at 13:04, Artyom Katsap notifications@github.com wrote:

A question here: We have departments managed in two places - spark and volunteers db. We should have it stored in one db and make this accessible via API

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

ArtyomKa commented 6 years ago

1 - Elad, if you bring the "know how" I'll help to make it happen. 2 - We are talking about user permissions and module permissions as the same thing. Don't know if it is. I think it is different things that might (or not) share implementation details.

ghost commented 6 years ago

In order to allow max flexibility, what we did was give each route (including its route parameters, HTTP verb, etc) a permission.

Once you have permissions at that granular level, you can mix and match them on both the user level and role level.

For the implementation I did for work we also had groups and hierarchy between different roles and different groups, for permission inheritance, but that would be overkill for our current requirement.

Also, I think that now is a good time to discuss and evaluate if we want to move to a CMS, because if so, I believe we will get a more robust solution out-of-the-box. Another important point is we will also get the user management GUI for free, which is another thing will need to implement sooner or later.

On 31 Jan 2018, at 8:35, Artyom Katsap notifications@github.com wrote:

1 - Elad, if you bring the "know how" I'll help to make it happen. 2 - We are talking about user permissions and module permissions as the same thing. Don't know if it is. I think it is different things that might (or not) share implementation details.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

OriHoch commented 6 years ago

we are using this for auth / permissions etc.. https://github.com/datahq/auth

I think it does everything that you need

OriHoch commented 6 years ago

and the related angular component - https://github.com/openbudget/budgetkey-ng2-auth - you can see the auth service

you can authenticate 3rd party modules with this central auth service, here is an implementation I'm working on at the moment (using python but can easily be done in any language) - this code verifies with the auth server from the 3rd party module

OriHoch commented 6 years ago

this is what I'm working on every Monday before I come to the Midburn meeting :)

ghost commented 6 years ago

Nice!

I’ll take a look later. This might be a good option, if we decide not to go the CMS route

On 31 Jan 2018, at 9:57, Ori Hoch notifications@github.com wrote:

this is what I'm working on every Monday before I come to the Midburn meeting :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.