oc-doc/docs/WP/authentication_access_control.md

## 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 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 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 

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

On a remote instance basic permission are :
* exceute workflow (quota + peers subset ?)
* store data (quota + peers subset ?)
  

## Authentication process

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 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/