Enhancement: Add extendable permissions system

[strangeman]

For security reasons, we need user, who doesn't allowed for edit the tasks. It should be only able to launch tasks.

So, project should have 3 levels of permissions:

• admin can add new users to the project, create/edit project components (task templates, inventories etc), launch tasks
• user (editor?) can create/edit project components (task templates, inventories etc), launch tasks
• 'read-only' user (user?) can launch tasks

[twhiston]

I would love to see this happen if you are willing to do it. Would be a great feature! If you are up for it i'd like to add a 2.6.0 label to it and try to get it in to first release after the current cleanup and merge release i'm putting together

[strangeman]

Ok. Current PR (#413) was more like the temporary solution.

[twhiston]

As discussed in #413 we will try to revisit this in a more robust way, implementing some kind of permission system that allows easy extension. We should see what existing libraries exist already that we could use to implement this, and decide on the final scope of the changes

[twhiston]

Looking at the code while i've been going through the linter errors it seems like we could move the logic for this out to middleware, and implement or integrate something at that point to keep things fairly decoupled. We should move existing bits of permissions checking out of the api route functions as well.

[Glandalf]

Hi,

If this is still a subject, I have a strong need in my company.

May I try to implement it with simple permission system bellow?
For each user (in the Team tab) we could add a checkbox for:

• the ability to add/modify repositories Y/n
• the ability to add/modify keys (in key store) Y/n
• the ability to add/modify environments Y/n
• the ability to add/modify inventory Y/n
• the ability to add/modify task templates Y/n
• the ability to add/modify team members? Y/n (might not be relevant)

Being administrator should bypass the permission system

Design proposal

Database

I propose a new user_permissions table that could look like this:

user_id (FK -> user.id)
project_id (FK -> project.id)
resource (possible values: environment|inventory|repository|template|access_key)
PK (user_id, project_id)

One row = the ability to create/update the given resource on a given project for the given user.
We could even add a method field (based on the REST verb) explaining if user can create/read/update/delete to be more precise (not useful in my case and might be overkill for a first version?).

Backend middleware

We then might handle credentials in every middleware in https://github.com/ansible-semaphore/semaphore/tree/develop/api/projects files or more globally in https://github.com/ansible-semaphore/semaphore/blob/develop/api/router.go?

Backward compatibility

For users not needing this feature, we could just add a permission_system flag in the project table:

• if not enabled, this new system is bypassed
• if enabled, middleware "guards" are used

Feel free to propose enhancement and to tell me if I should start dev.