This service provides an oCIS extension that wraps reva and adds an opinionated configuration to it.
The below diagram shows the oCIS services and the contained reva services within as dashed boxes. In general:
- A request comes in at the proxy and is authenticated using OIDC.
- It is forwarded to the oCIS frontend which handles ocs and ocdav requests by talking to the reva gateway using the CS3 API.
- The gateway acts as a facade to the actual CS3 services: storage providers, user providers, group providers and sharing providers.
The dashed lines in the diagram indicate requests that are made to authenticate requests or lookup the storage provider:
- After authenticating a request, the proxy may either use the CS3
userprovideror the accounts service to fetch the user information that will be minted into the
- The gateway will verify the JWT signature of the
x-access-tokenor try to authenticate the request itself, e.g. using a public link token.
The bottom part is lighter because we will deprecate it in favor of using only the CS3 user and group providers after moving some account functionality into reva and glauth. The metadata storage is not registered in the reva gateway to seperate metadata necessary for running the service from data that is being served directly.
In order to reason about the request flow, two aspects in the architecture need to be understood well: