27 lines
1.4 KiB
Markdown
27 lines
1.4 KiB
Markdown
|
# 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.
|
||
|
|
|
||
|
|
# Users / roles / groups
|
||
|
|
|
||
|
|
|
||
|
|
# User permissions definition
|
||
|
|
|
||
|
|
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,...)
|
||
|
|
|
||
|
|
# 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, ...)
|
||
|
|
A collaborative workspace
|
||
|
|
|
||
|
|
|
||
|
|
# Resources don't have an 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
|