core/oc-doc
6
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

workflow rules

Browse Source
This commit is contained in:
ycc
2025-01-29 09:42:05 +01:00
parent b31134c6cd
commit faa21b5da9
3 changed files with 93 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/WP/authentication_access_control.md
View File

@@ -1,27 +1,33 @@
# General architecture
## General architecture
Each OpenCloud instance will provide an OpenId interface. This interface may be connected to an existing LDAP Server or a dedicated one.
The main advanytage of this distributed solution is that each partner will manage it's own iusers and profiles. It simplifies access control management as each peer does not have to be aware of other peers users, but will only define access rules globally for the peers.
The main advantage of this distributed solution is that each partner will manage it's own users and profiles. It simplifies access control management as each peer does not have to be aware of other peers users, but will only define access rules globally for the peer.
# Users / roles / groups
## Users / roles / groups
Users in opencloud belong to a peer (company), they may be part of groups within the company (organisational unit, project, ...).
Within those groups or globally for the peer, they may have different roles (project manager, workflow designer, accountant,...).
Roles will define the list of permissions granted to that role.
## User permissions definition
# User permissions definition
Each OpenCloud instance will manage it's users and their permissions though the user/group/role scheme defined in the previous chapter.
On a local instance basic permissions are :
* a user has permission to start a distributed workflow using remote peers
* a user has permissions to view financial information on the instance
* a user has permissions to change the service exchange rates
Each OpenCloud instance will manage it's users and their permissions :
On a local instance :
* a user has permission to start a distributed workflow in using remote peers
* a user has administrative rights and may change the service exchenge rates
* a user is limited to view financial information on the instance
* a user belongs to a group (that may represent a project, a department,...)
On a remote instance basic permission are :
* exceute workflow (quota + peers subset ?)
* store data (quota + peers subset ?)
# Authentication process
## Authentication process
Each OpenCloud peer will accept a company as a whole.
Upon user connection, it will receive user rights form the origninating OpenId connect server and apply them. ex: specific pricing for a group (company agreement, project agreement, ...)
Each OpenCloud peer will accept a company/group as a whole.
Upon user connection, it will receive user rights form the originating OpenId connect server and apply them. ex: specific pricing for a group (company agreement, project agreement, ...)
A collaborative workspace
# Resources don't have an url
## Resources don't have a static url
They will map to an internal url of the service
Once a workflow is initialized and ready for launch temporary urls proxying to the real service will be provided to the wokflow at booking time
Once a workflow is initialized and ready for launch temporary urls proxying to the real service will be provided to the wokflow at booking time/