search

cs3org / wopiserver

A vendor-neutral application gateway compatible with the WOPI specifications.
Apache License 2.0
52 stars 27 forks source link

REVA JWT secret should only be used internally #35

Closed wkloucek closed 3 years ago

wkloucek commented 3 years ago

If I want to use the /wopi/iop/open endpoint, I am forced to 1) know and 2) to send the REVA JWT secret over the wire

This is not great from a security viewpoint since this secrets allows anybody to mint REVA access tokens which allow one to access all file in REVA.

1) can be circumvented by only validating the REVA access token in the TokenHeader header. The user / service using /wopi/iop/open then only needs to provide a REVA access token and does not need to know the REVA JWT secret anymore.

2) If such a password protection is need, a dedicated password should be used, which can not be used to mint arbitrary REVA access tokens.

CS3org WOPI server still needs to know the REVA JWT secrets because it is actively issuing REVA JWT tokens.

Background: Our oCIS WOPI server extension should have no need to know the REVA JWT secret. The only place left where it is needed is the call to /wopi/iop/open. (All other places where it is currenlty still needed will be removed in https://github.com/owncloud/ocis-wopiserver/pull/6/files)

The following diagram describes the request flow when a user is opening a file:

auth

@glpatcern please let me know what you think about this. I can create a PR next week if you like the idea

wkloucek commented 3 years ago

I just noticed that my diagram posted in the description is not correct because 12) is not happening. Instead the REVA access token from 4) is embedded in step 13).

I was confused by the cs3.authtokenvalidity config option (https://github.com/cs3org/wopiserver/blob/e4b757431ccff075e344b35935a3aee3f4dd7cde/src/cs3iface.py#L35) which I though is used to mint a REVA access token with longer lifetime but instead it is unused.

glpatcern commented 3 years ago

Hey there, I surely like the principle, though I was a bit unsure how the effective minting of REVA access token could happen. And yes, the cs3.authtokenvalidity config option is actually a left-over: initially it was meant to extend the validity of the received token, but there's no code for that - and I wonder whether to remove that option altogether, given that it is conceivable to have any WOPI access token's validity not longer than the user token validity it originated from.

One thing for sure is that the WOPI server needs to access not only the file it is requested to by the user, but also the containing folder in order to check/create the lock files. This is why it's using a "full" user token for now, and an application token or the like must be carefully thought through to still grant all required actions.

glpatcern commented 3 years ago

Willy, if you want to have a direct chat (e.g. in gitter?) I'm happy to further discuss this.

wkloucek commented 3 years ago

Sorry, I have been busy fore the last few days.

As a first step I would like to make authentication with the bearer token possible on the /iop/open endpoint, so that the REVA JWT secret doesn't need to be sent.

I opened a PR wich would allow that: https://github.com/cs3org/wopiserver/pull/36. What do you think about it? (It should be fully backwards compatible)

glpatcern commented 3 years ago

OK, the PR helps understanding the concern. But the WOPI iopsecret is not (or should not!) correspond to the Reva JWT secret: this secret is a dedicated shared secret between Reva and WOPI, nobody else should need to use it. In particular, even the WOPI server does not reuse it when talking back to Reva as storage provider.

At this point I'm not sure what we're trying to solve... shouldn't be enough to not reuse in Reva the AppProvider's iopsecret value anywhere else?

Edit: following the sequence diagram, my question above should actually read: if the oCIS WOPI server is the only daemon interacting with the CS3 WOPI server, bypassing the open-in-app logic in Reva, then the iopsecret to be used is shared secret between the oCIS WOPI server and the CS3 WOPI server only. Reva should NOT know about it at all.

wkloucek commented 3 years ago

Thanks for clarification, this makes this whole issue obsolete.

My misunderstanding was caused by the "shared secret used by your EFSS" (in docker/buildimage_wopiserver.sh), because for oCIS, the REVA JWT secret is also a shared secret. But that was to much interpretation from my side ;-)

I updated the sequence diagram to reflect the shared IOP secret: image

Edit: following the sequence diagram, my question above should actually read: if the oCIS WOPI server is the only daemon interacting with the CS3 WOPI server, bypassing the open-in-app logic in Reva, then the iopsecret to be used is shared secret between the oCIS WOPI server and the CS3 WOPI server only. Reva should NOT know about it at all.

Right, we are not using the AppProvider currently, therefore Reva is not involved except to stat and up/download the file.

glpatcern commented 3 years ago

Thanks for the update and for the detailed sequence diagram, that helps anyway for our understanding! All clear then, I will add a comment to the script so that the scope of the shared secret is clearly stated.

wkloucek commented 3 years ago

Thanks for the update and for the detailed sequence diagram, that helps anyway for our understanding! All clear then, I will add a comment to the script so that the scope of the shared secret is clearly stated.

Thank you for your help :-)