Skip to content
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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authorization / Permission Model for openDuT #297

Open
mirenz1 opened this issue Aug 26, 2024 · 1 comment
Open

Authorization / Permission Model for openDuT #297

mirenz1 opened this issue Aug 26, 2024 · 1 comment
Labels
component: carl Mostly related to CARL. component: carl-api Mostly related to the opendut-carl-api component: documentation Mostly related to documentation type: feature Fulfills a need or requirement by providing a complete new functionality.

Comments

@mirenz1
Copy link
Contributor

mirenz1 commented Aug 26, 2024

A permission and role model shall be introduced to openDuT in order to manage authorizations for different resources used in openDuT.

Role description

1 basic_role

  • default for every user with openDuT access
  • can create own peers

1 user_role per peer

  • allows administrating a specific peer and creating new clusters using this peer
  • creating a cluster is only possible, once a user has at least an user_role or owner_role on for least 2 peers (cluster with only one peer cannot be saved anyhow)

1 owner_role per peer

  • every peer has an owner --> creator of peer by default
  • can do the same with a peer as the user_role, but has extended permissions
  • can assign/unassign other users to the user_role of the owned peer

1 admin_role

  • system administrator for openDuT

Permission - Role matrix

Permission BASIC USER OWNER ADMIN
create new peers x x
edit peers po po x
add devices to peers po po x
remove devices from peers po po x
configure execution container for peer po po x
create setup string for peer po po x
delete peers po po x
view peer configuration x x x x
--- --- --- --- ---
create new cluster po po x
edit cluster name po po x
add devices of peers to cluster po po x
remove devices from cluster po po x
define lead peer for cluster po po x
delete cluster po po x
view cluster configuration x x x x
--- --- --- --- ---
deploy cluster po po x
undeploy cluster po po x
--- --- --- --- ---
add/remove other users as USER of peer po x

Legend:
x ... general permission granted
po ... peer only, peer specific role grants permission only for the specific peer

Discussion

  • What happens, if you have a cluster with devices/peers and your access to one of the peers has been withdrawn?

    • you cannot see and use that cluster anymore
  • Can you only work with clusters, where you have permissions for all used peers?

    • yes
  • Do we really want that everyone can see all peers and clusters?

    • would help to share peers, when other users can see what is available to ask the owner for permission to use it
    • could become confusing seeing too many peers, may need filtering options

References

Relates to #290

@github-project-automation github-project-automation bot moved this to Backlog in openDuT Aug 26, 2024
@mirenz1 mirenz1 added component: documentation Mostly related to documentation type: feature Fulfills a need or requirement by providing a complete new functionality. component: carl Mostly related to CARL. component: carl-api Mostly related to the opendut-carl-api labels Aug 26, 2024
@hafklin
Copy link
Contributor

hafklin commented Sep 9, 2024

This looks like a pretty solid approach to me! To me it also seems like this won't overly complicate extending the permission model to the file storage functionality (which is currently still the crude WebDAV server).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: carl Mostly related to CARL. component: carl-api Mostly related to the opendut-carl-api component: documentation Mostly related to documentation type: feature Fulfills a need or requirement by providing a complete new functionality.
Projects
Status: Backlog
Development

No branches or pull requests

2 participants