Shared secret for the Remote config

[kendy]

To be able to add access token for the convert-to endpoint, it is necessary to setup trusted communication between the COOL and integration for Remote config.

The idea is that the Remote config URL will contain a token, that will be then used while requesting the Remote config from the integration.

Then - this remote config will define a token for the the convert-to endpoint.

@juliushaertl: Please do you have a preferred format for those URL's / tokens?

[juliusknorr]

I've been thinking about this one a bit more especially in terms of making the setup and connection to Nextcloud easier.

My proposal would actually be to have just a shared secret which could then be used to set the remote configuration from the Nextcloud side. Considering adding an endpoint to set the remote config url from outside, providing the shared secret it would be possible to have a very easy setup flow:

• Install collabora, maybe pre-generate the secret and show it or have something like coolconfig set-shared-secret abc123
• Enable the richdocuments URL, provide the Collabora server URL and shared secret
• Nextcloud can then call the new endpoint e.g. /hosting/configure to set its own remote config url
• All follow up configuration can be handled automatically through existing remote configuration handling

This saves the following steps:

• Manually configuring the WOPI host groups in coolwsd.xml
• Manually configuring the remote config url
• We can in a second step already verify connectivity at the time Nextcloud sets the remote config url to show more useful hints to the admin about issues with the configuration or connection between both services

@pedropintosilva Who would be the best from your side to check if such an approach makes sense to you?

[eszkadev]

cc @Rash419

[mmeeks]

@juliushaertl can you outline how the shared secret is exchanged ? =) how does Nextcloud verify this ? do we transfer the secret, or a crypted version of that ? or ... If we want to verify that a message is coming from COOL to Nextcloud - we should use the existing X-WOPI-Proof-key mechanism that handes timestamps, and crypto properly - we shouldn't invent a new mechanism I think. If we want to verify that COOL is connecting to the right Nextcloud server then we could of course have a key there; but I guess I'd really prefer Nextcloud to verify proof on a request for configuration from COOL - and then pass whatever secrets are needed across an https:// channel to COOL to pass back later (?) =) that'd help making cluster admin easier I guess. @Rash419 not sure how WOPI-proof key distribution over a cluster works currently though :-)

[juliusknorr]

As far as I remember proof key handling would only allow verifying that the WOPI requests originate from the Collabora server when it calls the Nextcloud server. The secret here would be for requests towards the other direction which is nothing that the WOPI standard currently covers. I'd rather stick to a simple secret for that as setting up crypto keys might be yet another hurdle for average admins there.

The exchange would be the only manual step then, where the shared secret is configured or autogenerated on the Collabora server and then configured in the admin UI of Nextcloud together with the URL of the Collabora server.

I think we should be fine just transmitting the secret in a POST request then as we'd recommend transport encryption using HTTPS anyways, but we could of course also think about some public/private key mechanism here.

[mmeeks]

Ah - fair cop - so, with the remote configuration stuff; we can fetch this key from you - and associate it with your server - such that we then trust requests with that shared secret coming from you ? =) if so, make perfect sense - and/or we can have users code it into the configuration too of course :-) for remote config to work nicely you'd want to use WOPI proof to check the request for remote config came from us - and we would need to add that which is quite some work.