Authorization / Permission Model for openDuT

[mirenz1]

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

• We should differentiate between technical clients (CLEO/EDGAR). Credentials used by EDGAR should not be allowed to manage peers and clusters or use the administrative endpoints in general. See #385.

References

Relates to #290, #385

[hafklin]

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).