Find a way to make Tobira work with Opencast's static file authorization

[LukasKalbertodt]

By design, Tobira uses URLs to Opencast assets and media directly. This means that in the frontend, there might be an <img> or <video> tag loading from an Opencast URL. Since users only authenticate against the Tobira domain, usually unaware of the Opencast in the background, all requests for assets/media are unauthenticated. Since Opencast 10, static file authorization is enabled by default. This means that Tobira users cannot access assets/media that is not accessible by ROLE_ANONYMOUS.

This is obviously not great. Possible solutions:

• Disable static file authorization. It's not great. However, it's just like in pre-10.0 days, so yeah, it works.

• Tobira could proxy all requests through itself. This means Tobira can authorize the user and then access the asset/media with its admin privileges. This has the disadvantage of potentially high overhead. While, even naively coded in Rust, I don't think it produces lots of CPU load, the network is still heavily utilized (2 uploads & one download instead of only one upload). If both VMs are in the same data center or even on the same machine, it could work fine. But yeah, it's certainly not optimal, performance wise.

• Tobira could authenticate the user's browser in the background, for example via LTI. This is what lots of LMSs do.

• Tobira could append special query parameters to the URLs that are then used by Opencast to authenticate the user or authorize the request. For example, the query parameter could contain a JWT with some auth information.

[LukasKalbertodt]

More thoughts:

• One could actually consider mounting the same NFS in the Tobira VM so that Tobira can serve the files directly.

• I'm not sure the LTI approach would work, as this just creates a user sessions but the cookies are not included in these kinds of third party requests, right? We could look closer at how LMSes do it.

• JWT could work, but right now with OC's implementation I don't think it's a good option. JWT in Opencast, as far as I understand, can only be used to authenticate a request as a user. Which would certainly work, but would bring lots of problems regarding the JWT duration. With infinitely long living JWT -> no problem. But that's not safe. The problem is that if the JWT is stolen, it can be used to authenticate as that user to any endpoint. Instead, I think what one wants is to just sign one link as to tell Opencast: "This token included in the link allows access to anyone within this time period". If the token is stolen then, the thief can only access that specific file with it and do nothing else. While generally JWTs can do that, I don't think the OC implementation can.

[LukasKalbertodt]

See this discussion: opencast/opencast#5334