proposal: role based authorization

[steadfasterX]

background

usually you have at least 4 groups of persons accessing a tool like that:

1. global admins (full access to everything, everywhere)
2. project admins (full access to a project - only)
3. project users (specific action permissions in a project, e.g ability to click the build button but not modding an inventory etc)
4. readonly users (no action permissions, never)

what I currently see in semaphore is 1. and partly 2 with some kind of non-admin access which basically is not what I would expect when thinking of a "non-admin" user.

Semaphore already has the ability to choose team members for a project which is great and should "just" ;) be extended to a more specific role / group based system. I have not looked into LDAP yet but when implementing that it should match LDAP groups/netgroups in order to make use these here, too (e.g. LDAP group "semaphore_projectadmin_abc" will become a project admin of project "abc" in semaphore).

Permissions

global admin permissions

• like the current admin user
• all permissions of a project admin but for every project (see next topic)

project admin permissions

basically this is what an admin and even a non-admin user (when added as a team member) can do already except the user management part, of course.

when a user is added to a project and having project admin rights he should have the permission to:

• add/remove other team members
• set/unset a team member as project admin
• set/unset a team member as project user
  • set/unset a project user permissions: allow edit inventories/repos/..., allow to build/rebuild, ..
• set/unset a team member as readonly user
• full access to everything in that project, i.e. add/remove inventories, tasks, etc and do actions (build,rebuild etc)

project user permissions

• whatever has been set by an admin or project admin (see above)

readonly user permissions

• basically view / show everything where that user is member of - without any ability to modify
• optionally it would be nice to block changes of the own account (password, mail,..) so one can share that account with a wider audience

conclusion

I strongly believe that enterprise users require the above and that prevents them for actually using semaphore or at least offer it to their users. I would really appreciate seeing the above or at least parts of it in semaphore as actually atm I cannot share it with others without these changes.. I would love to contribute but absolute zero experience with Go - while I really love the look & feel & idea of semaphore..

for a first run I would be more then happy if we could have a readonly user permission and a simple project user permission where everything is blocked but actions like build/rebuild are allowed. The rest would be step 2..N then :)

refs:

• Add non-privileged user role #405
• Add launch-only property for project users #413
• Add an authorization mechanism based on Casbin #368
• Simple authorization via LDAP #310

[fiftin]

Hi @steadfasterX

Thank you very much for your feedback!

[bendem]

This makes a lot of sense. Currently, we cannot give access to semaphore to developers or analysts because that would give them too much permissions (easy to break something by mistake).
The roles mentioned make sense, devs would be project users, analysts readonly users.

As for the LDAP, I would differentiate user role and project assignment. For project assignment, I would suggest adding an external id field to the project. If a user is in a group that matches that id, it is added to the project's team (kind of what exists in bookstack). User role can be in the config, with a mapping of the type "role_name": "ldap_group_name".

[macau23]

Does this PR allow for per-task permissions?
i.e. I need to allow a user to run a specific task (but not all tasks) belonging to a project.

[steadfasterX]

One additional note: the implementation also should handle access tokens (see #1391)

[fiftin]

Hi @steadfasterX do you still use Semaphore?

[steadfasterX]

Every day 👍😎

[fiftin]

@steadfasterX Glad to hear that :) Do you have any wishes or suggestions for improving the Semaphore?

[steadfasterX]

@steadfasterX Glad to hear that :) Do you have any wishes or suggestions for improving the Semaphore?

@fiftin : yesss.. :)

there is one major pain point atm (1344):

• sharing tasks between different projects
• exporting & importing tasks (incl all dependencies like env, inventory) with other semaphore instances
• exporting & importing a view (incl all tasks and its dependencies like env, inventory, etc within)

and an important regression - importing a project backup has issues:

• the survey variables do not get imported at all (while they exist in the backup)
• the cron gets imported but never fire - deleting the cron entry, saving, re-add works though

and some other regressions (from high to low prio ;) ):

• when using the task editor to add a survey variable you can only choose between "string" and integer but I often need "boolean" instead. the reason is that "string" will place it with quotes forcing ansible to use it as string and integer does not allow to input a string.. this makes it harder to do stuff like when: myvar within ansible (when: myvar | bool is a workaround but that is annoying to do on tons of existing stuff) - EDIT: this is still the case in latest beta and when using the new input method
• no proper time display - (FIXED in beta)
• admin permissions required for the API (should be part of the RBAC so you can choose e.g. to allow starting a task ir just readonly etc)
• especially the environment screen is very hard to use when you have multiple envs and want to find the edit button for it on big screen monitors.. (see Feature: improve some parts of the UI which are hard to use currently #2398)
• tasks which produces a LOT of output (hundreds of lines) will totally mess-up the whole output (also in Feature: improve some parts of the UI which are hard to use currently #2398)