Collaboration proofkeys

[jvillafanez]

Description

Add support for proof keys. These will be used to ensure that the calls coming to the collaboration service comes from a trusted source.

Most of the technical details can be found on https://learn.microsoft.com/en-us/microsoft-365/cloud-storage-partner-program/online/scenarios/proofkeys

The proofkeys verification will be enabled by default. This could cause problems if the WOPI app doesn't support the feature, it doesn't have the keys ready, or there are bugs in our side. In order to not disturb the system too much, this feature can be disabled on our side (collaboration service) so the verification won't happen and all the requests will be allowed. Note that you'll need to restart the collaboration service after changing its configuration.

In addition, the retrieved keys from the discovery (required for the verification) will be cached in memory for 12 hours by default. It's expected that the WOPI app rotates the keys so we'll need to fetch them again periodically. You can adjust the caching period in order to ensure we get updated keys periodically, otherwise the verification could fail.

Related Issue

No open issue

Motivation and Context

This should increase the security because all the allowed requests should come from a trusted source.

How Has This Been Tested?

Manually tested with OnlyOffice

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[jvillafanez]

Unit tests seems quite difficult to add. We'll need to generate private keys in order to set the proof signature, and also to store the related public keys, which should be fetchable from somewhere (likely a dummy server).

Some basic end-to-end test with any WOPI app with proof keys configured should be enough to know whether the feature works or not because any request done to the wopiserver will be rejected if the verification fails. If the proof keys are generated automatically when the WOPI app starts, then the integration should work without configuring any additional thing on our side.

[micbar]

General question:

Are the proofkeys kept in memory?
If that's the case, the service cannot be scaled.

[jvillafanez]

The actual proofkeys come from the "/hosting/discovery" endpoint of the WOPI app. According to Microsoft docs, the keys change from time to time (I've read somewhere that they change the keys each 12 hours, but I'm not sure), so the collaboration service will cache the keys in memory for 12 hours before requesting the new keys again.

Even if the keys are cached individually in memory, it's just a local cache. There is no problem with scaling on our side. The collabotation service's replicas will eventually have the same keys.

The proposed algorithm for the verification in the official docs also takes into account possible time shifts (you get the "latest" keys and one hour later the WOPI app changes the keys; or the WOPI app sends the proof with the previous key), so they shouldn't be any problem if we cache the keys within the time range of the rotation.

The only potential problem is if we need to scale the WOPI app somehow, although I guess it's a problem the WOPI app should solve, not us. I mean, if we need to scale OnlyOffice to 3 instances, it's up to them how to do it, but I'd expect all the instances to share the same keys.
Worst case, we can disable the verification on our side in order to not disrupt the system.

[micbar]

Thank you for the explanation. That works for me.

[micbar]

From a code POV it looks good. I cannot test the fuctionality.

BTW: Which WebOffice suites are using ProofKeys?

Background of the question: We are using collabora as the default. I see no proofkeys on the hosting/discovery response. Therefore it might be better to keep the feature default off.

[jvillafanez]

OnlyOffice have some keys set by default, although for production they should be generated (I'm not sure how, I was testing with the default ones)

For Collabora, I think you need to run the coolconfig generate-proof-key command inside the Collabora container in order to generate the keys. I'm not sure if such command should be run by default during installation (or container startup) though.

As said, the keys are expected to rotate after a while, but I don't know if that will be taken care automatically by the WOPI app or the admin will need to do something else. If the key rotation happens faster than each 12 hours, the admin will need to adjust our COLLABORATION_APP_PROOF_DURATION accordingly.

[jvillafanez]

For Collabora, I think the best option is for them to handle the generation of the proof keys on startup. They could provide an environment option to generate the keys.
They also don't seem to update the keys anyhow (at least I don't see a way to do it). This means that both the old and new keys will be the same, and there won't be rotation of the keys.

For the short term, I guess the easiest option is to include the following command in the docker-compose file (collabora section):

command: ["bash", "-c", "coolconfig generate-proof-key ; /start-collabora-online.sh"]

That should generate the proof keys right before starting Collabora. If the keys exist, the coolconfig will fail but Collabora will start regardless. This also means that the keys won't change when the container is restarted.
The only potential problem is that, if the proof keys changes, the collaboration service will need to be restarted too in order to clear the cache and request the updated keys from the "/hosting/discovery" endpoint. This restart shouldn't be needed if the keys rotate.

[sonarcloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
2.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud