clients might be able to create pre signed urls with a random key generated using ocs: owncloud/ocis-ocs#18

the proxy needs to be able to authenticate a request, in a similar fashion as for oc10 owncloud/core#37634

if we talk directly to ocis-store we would bypass ocis-ocs, who is responsible for the data. instead we need to add an rpc call to ocis-ocs to validate the signature of the request.

If done properly this is an independent service, similar to the reva auth basic, aith bearer or auth publictoken auth service instances that are responsible for authenticating requests.

Spec: ocis-proxy must include account's uuid on authenticated requests

Gathered Requirements

• having UUID on every request on the proxy
• user object upon authentication (phoenix).
• make js generated from swagger do requests through the proxy instead of the service.

Formal Requirements

Phoenix has no knowledge of which Ocis Account the authenticated user has on the ocis-accounts service. A design proposal is to render the Ocis Account UUID on every request that goes through the proxy. This should allow extensions to request its configuration values from the Settings Service based on the account uuid.

I identify changes in the following services:

• Ocis Proxy
  • need to know where the Ocis Accounts service is running.
• Ocis Accounts
  • query message needs to be more flexible. key alone is not enough to query for an account. Adding some of the user claims could be used for querying the account files.
• We need the middleware for adding the account uuid of the authenticated user to every request. That could be used for validation mechanisms when the authenticated user is impersonating another user (i.e. checking through roles & permissions, if the authenticated user is allowed to impersonate the other user). (Impersonation as in e.g. retrieve settings values for another user, not talking about full frontend impersonation)
• Extensions will do a first call to the ocis-accounts

This flow can be achieved with a middleware in the Proxy. With this UUID an extension can then request its settings to the settings service through the proxy.

How do we want to consume the UUID

• Response header
• Response payload

Ubiquitous Language

• Ocis Accounts: refers to github.com/owncloud/ocis-accounts
• Account UUID: refers to the account's UUID. This UUID only exists in the account service.

Links of Interest

• Request Flow | ownCloud

in ocis-accounts accounts have an account_enabled flag which the proxy should evaluate.

I'm getting an unknown internal server error with no logs

Steps to reproduce:

1. checkout master on this repo
2. checkout to owncloud/ocis -> master
   2.1 replace github.com/owncloud/ocis-proxy => ../ocis-proxy (your local proxy)
3. go run cmd/ocis/main.go server
4. on the browser: https://localhost:9200

expected: see login screen
got: internal server error

While a proxy without policies is of no use, the current state of ocis-proxy expects a config file either at an expected Viper location or specified via -- config-file flag.

To ease deployments and ensure a working set of policies out of the box™️ we need a series of defaults.

similar to revas auth provider we need to tell the reva gateway to create the users home storage:

	// create home directory
	createHomeReq := &storageprovider.CreateHomeRequest{}
	createHomeRes, err := s.CreateHome(ctx, createHomeReq)
	if err != nil {
		log.Err(err).Msg("error calling CreateHome")
		return &gateway.AuthenticateResponse{
			Status: status.NewInternal(ctx, err, "error creating user home"),
		}, nil
	}

	if createHomeRes.Status.Code != rpc.Code_CODE_OK {
		err := status.NewErrorFromCode(createHomeRes.Status.Code, "gateway")
		log.Err(err).Msg("error calling Createhome")
		return &gateway.AuthenticateResponse{
			Status: status.NewInternal(ctx, err, "error creating user home"),
		}, nil
	}

This needs to happen after the user has been authenticated, the account has been resolved and a token has been minted. It should go into a dedicated createStorage middlewaret that is chained after the account_uuid middleware

2 Steps ticket:

• Routing to multiple backends (n-backends) (multiple reva or oc10 instances) SHOULD be allowed.

• Proxy processes the Authentication header for the bearer token to fetch the user and decide whether it should be routed to reva or oC10.

Tracking: https://github.com/owncloud/enterprise/issues/3880

when the accounts service does not know an account (either by email, username, or custom claim) ocis-proxy should provision the user on the fly. should happen in a dedicated middleware that can be disabled via the config.

followup tasks

• only for certain email domains?
• only when the user is known in ldap?

Currently, the create_home middleware will always try to send a create home request. We should omit that when the user has not been migrated and still lives in oc10.

This is needed if the proxy runs behind another TLS-Terminating reverse-proxy.

2020-03-04T22:49:39+01:00 INF Starting server addr=0.0.0.0:9200 service=ocis transport=https

Should log with service=proxy instead.

Add options to restrict which http methods are allowed for pre-signed requests.
Currently we only want the clients to GET resources.

For certain requests e.g. the webdav preview request, the URL is the same as for the file download. The only difference is one query parameter.
Therefore we need a method to route requests based on different conditions.

Steps

1. Checkout ocis and ocis-proxy repos from git (both master)
2. In ocis repo, edit go.mod to replace ocis-proxy using the local checkout
3. Run make clean build

Expected

Compiles fine.

Actual

rm -rf config/identifier-registration.yaml
go clean -i ./...
rm -rf bin dist hugo
go build -v -tags '' -ldflags '-s -w -X "github.com/owncloud/ocis/pkg/version.String=284a999" -X "github.com/owncloud/ocis/pkg/version.Date=20200625"' -o bin/ocis ./cmd/ocis
github.com/owncloud/ocis-migration/pkg/command
# github.com/owncloud/ocis-migration/pkg/command
../../../../go/pkg/mod/github.com/owncloud/[email protected]/pkg/command/import.go:130:15: ss.Set undefined (type "github.com/owncloud/ocis-accounts/pkg/proto/v0".AccountsService has no field or method Set)
../../../../go/pkg/mod/github.com/owncloud/[email protected]/pkg/command/import.go:130:32: undefined: "github.com/owncloud/ocis-accounts/pkg/proto/v0".Record
make: *** [Makefile:101: bin/ocis] Error 2

This is a blocker for any further work on the proxy, like #45

@micbar @butonic @kulmann FYI

This fixes listing received shares and probably a few other things.

Idp-Url is used to match for received shares.
https://github.com/cs3org/reva/blob/9e49158a5a34786e3c948b484d78f5c01f4800ff/pkg/share/manager/json/json.go#L367

Proxy AccounUUID middleware should also add the idp url to the token

So far, when uploading with TUS, the clients receive a Location header that usually points directly to the port 9164

As far as I understand in deployment scenarios where the proxy is used, we'd want to have that one also routed through the proxy.

We could provide an endpoint "/data" and forward it to 9164.

@butonic does that make sense ?

URLs required for the client are missing in the default-config.