How to make external applications (e.g. LMS, Tobira) work with Opencast static file authorization?

[LukasKalbertodt]

In Opencast 9.2, a new system for static files authorization (SFA) was added. This was enabled by default in Opencast 10. Without SFA, static files (such as video files, subtitle tracks, and thumbnail images) can be accessed by anyone. With SFA enabled, Opencast authenticates and authorizes the request as with any API request, for example, and might return 403.

This is a problem for some external applications, most notably LMSs (Ilias is even mentioned in the docs) and Tobira. That's because those applications just retrieve the URL to the video file from Opencast and then tell the users browser to load that URL. But that user might not have a valid Opencast session or the browser might not send session cookies for that 3rd party request. Even if there was an Opencast session, that's not guaranteed to have the same permissions as the LMS/Tobira session. Usually the LMS/Tobira has some extra information (like course membership) that's used for authorization and that Opencast does not have.
Either way: Opencast replies 403 and the user cannot watch the video.

The goal of this discussion is to arrive at a good solution that all of these external applications can use. That way we avoid duplicate work and prevent ending up with N different solutions. So ideally, people of every LMS would participate. Feel free to state opinions, report experiences or problems, or ask questions!

CC @mtneug @ferishili

Discussion meta

This uses GitHub discussion, which features "replies". So if you want to reply to a specific comment, use the text field right below that comment and not the one at the bottom of the page. This is not a linear discussion, like a GitHub issue! If you want to discuss two or more completely unrelated aspects, consider writing multiple top level comments to keep discussions focused.

---

Why not just disable SFA?

That's what's done in practice by everyone right now. I don't think that's acceptable, as that makes all videos essentially public. Yes, you do need the URL to the video file, but it's not impossible to obtain that (e.g. via other users or if the video was public before). YouTube URLs are also essentially unguessable, but it is still expected that no one can watch the video if it is set to private, even if the link has been leaked. Users have the same expectation for Opencast.

---

Possible Solutions

The core problem is that authorization and file serving are done by two different nodes. LMS/Tobira is supposed to have authorization authority, Opencast is supposed to serve the file if the user is allowed to access it (as decided by the LMS/Tobira).

Below, I am trying to enumerate all potential solutions to this problem. It's a bit of an abstract journey so that we are all on the same page. The summary is: I think the most promising solution is using JWTs to authorize every single request.

LMS/Tobira serves the files

LMS/Tobira could rewrite URLs to static files so that they point to its own domain instead of Opencast's. That allows the LMS/Tobira to do the authorization for the incoming HTTP request for the video file. To actually respond with the file content, the LMS/Tobira could act as a reverse-proxy and pipe the request to Opencast. But that's probably slow and infeasible. Instead, the Opencast NFS could be mounted in the LMS/Tobira VM and the files would be served from there.

But that might not be possible, as Opencast and LMS/Tobira might not even be running in the same data center. It's also a bit hacky as LMS/Tobira needs to rewrite URLs, and then parse the static file paths to determine the event to check against.

LMS/Tobira sends auth info to Opencast

The LMS could send some information to Opencast that allows it to decide whether a request is authorized. That can come in many forms, but all have one thing in common: Opencast needs to be able to somehow trust the information it is getting.

Theoretical excursion

There could be a secure and direct communication channel between the LMS and Opencast. But that authorized user's HTTP request still needs to be marked somehow, in order for Opencast to identify it and distinguish it from incoming requests that are not authorized. (This is possible via IP-address or even browser fingerprinting, but that's not a good idea.) Thus, we need to add some extra data to that request. This could look like this for example:

• The LMS backend generates a random ID.
• The LMS backend sends a message to Opencast over a secure channel: "allow the next incoming request with $ID"
• The LMS backend sends the ID to the frontend, which assembles the URL opencast.com/files/video.mp4?id=$ID.
• The users browser loads that URL and Opencast allows it due to recognizing the ID.

But since we have to add data to the HTTP request anyway (i.e. there is already a communication channel between the LMS and Opencast, albeit not secure), it would be convenient to not require this additional secure channel. We can do that by using cryptographic signatures. So:

The common solution to this is to let the LMS cryptographically sign the data in a way that Opencast can verify. That way, we can send the authdata+signature with the actual HTTP request via the user.

Create session vs. authorize single request

The LMS could send that authdata+signature to Opencast once, and Opencast would create a user session from it. That session is stored as a cookie and all further requests from the user's browser to Opencast will automatically be authorized via that session-cookie. This is exactly how LTI is currently used by some LMSs: the authdata+signature is POSTed to /lti. (Note: LTI is not the only way to do this! Opencast also allows creating sessions from JWTs, for example.)
Unfortunately, in many situation, this requires 3rd party cookies, which are soon disallowed by all browsers. So this isn't a viable solution.

So instead, every single request that needs authorization has to include the authdata+signature. This is not supported by LTI.

What auth-data to send

With the trust aspect solved, it's still unclear what data the LMS actually sends to Opencast.

• Use Opencast's role system: It might be possible to encode the LMS's authorization logic in the Opencast role-based authorization system. For example, the LMS could modify video's ACLs to include ROLE_COURSE_123_STUDENT. Later, when the user wants to request the video, the LMS can just send "this user has role ROLE_COURSE_123_STUDENT". Opencast then just evaluates its own authorization scheme (checking if the user roles and the event ACLs have an overlap) and allows the request based on that. Of course, not every authorization scheme is encodable in Opencast's role system.

• Give access to resource directly: Since the LMS already did the authorization, it just want to tell Opencast to "allow this request to video XYZ". That way, we can completely decouple authorization from content delivery. Further, this avoids sending any user-specific data (which is good). I see two implementation options:

  • Static file authorization plugin: that plugin would read the authdata+signature from the HTTP request and evaluate it directly.
  • Login handler + this PR: the login handler would inspect the HTTP request first, checking authdata+signature. If it's valid, there is a user session object for remaining request (as if the request contained a session cookie). That (temporary) user would get the specific role to give them access to that single resource.

JWT

JWT is the most popular standard to do what I said above we want: include authdata+signature in every request and grant access to a single resource only. It defines how to pack the authdata+signature into a single string (which is base64 encoded JSON objects + signature). That string can be appended to the URL as query parameter for example.

Opencast already has a login handler for JWTs, which can retrieve the JWT from an HTTP header or from a query parameter. How to map from the arbitrary authdata (inside the JWT) to user roles is defined via configuration (role mapping).

Restricting token power

Presenting the JWT to Opencast grants you certain permissions. If the token would just say "access to video 123", that would cause two problems:

• A user could send this token to a friend, which would then have the same permissions. (Since the token is included in the URL, this situation is not even that unlikely.)
• A user could store the token for a long time and still access the video years later, even if they shouldn't have access anymore (e.g. they left the university.)

JWTs usually contain an expiration date, which states that the token is only valid before said date. That solves the second problem completely, and helps a bit with the first one. One can go further and store an IP address or other information to identify the original user inside the JWT. Opencast would then only grant permission if all those infos match that of the requester.

But that in turn means that the web application (LMS/Tobira) must deal with potentially expired/invalid JWTs. What if the user opens a video, but closes the laptop, and tries to resume watching the video in a different network ten hours later? Yes, the user can fix it by reloading the LMS page. But ideally, the LMS/Tobira frontend would detect that the JWT is not valid anymore and issue a new one automatically. We certainly don't want weird "access denied" errors appearing without good explanation. Also note that the video file is usually not downloaded in one go, but just buffered slightly ahead of the user's play position. So in general, the JWT shouldn't expire faster than the video is long or the player/frontend needs to refresh the JWT while watching.

Consequently, this will increase frontend complexity. And I think that's the main disadvantage of this solution.
Ideally, we could implement all this logic once, to avoid every LMS implementing it on their own.

Stream Security?

Yes, this all is very similar to the "stream security" feature of Opencast. I have never personally worked with that, but as far as I understand, the implementation has its fair share of problems. Further, it's not using common standards like JWT. If anyone knows more and can evaluate whether it's useful to solve our problem, please tell us!

[oellers]

This is indeed a topic we are very interested in, as we have to deal with embedding opencast videos / player cross-origin for authorized users (and courses) on third-party websites, e.g., for research (formR, LimeSurvey), within learning modules (h5p, ...), on other web portals or LMS. Without taking a closer look, the approach of cross-site federation, SharedStorageAPI , Storage Access API or WebAuthn might be interesting for sourcing further ideas.

[Hufschmidt]

Another point against LMS/Tobira serves the files would be bandwith, as files would now be served by a (single) LMS Frontend Host instead of potentially (clustered) Opencast Presentation Host(s).

In regards to LMS/Tobira sends auth info to Opencast I would strongly prefer an authorize single request-based instead of an session-based approach as this can keep OpenCast stateless and simplify clustering for delivery/presentation nodes, where otherwise you might need to share session information between nodes.

I'm with you on the url/resource- vs role-based approach. I think being able to potentially decouple authorization from content delivery with the url/resource-based approach is a bigger advantage then potenially only having to create a single role-based auth-data request for all content related to an event/video.

Implementing this as a SFA Plugin does seem to make the most sense for me, as it puts the implementation closest to the related component without having to mess for global authentication/login, potentially opening unforseen side-effects with this new login method.

Another important point should be how the auth-data can be generated by the LMS, assuming the url/resource-based with JWT I think it is very important for performance that there should be an API for mass-signing URLs. (Thinking about having to sign all preview/segment thumbnails, all resolutions for presenter/presentation, subtitle file, etc.).

---

Apart from implementation details this does look kind of eerily similar to how Stream Security does it. 😉
But I guess that's kind of the point, to implement a newer version with better plugin/extension/customisation support. 👍

EDIT: After having read the original PR it seems like SFA and Stream-Security have slightly different goals:

• SFA wants to implementation static-file protection using OpenCasts ACLs
• Stream-Security wants to implement static-file protection using an external-system for Access-Control

[LukasKalbertodt]

Thanks for your comment!

API for mass-signing URLs

That's just an implementation detail of an individual LMS/Tobira, right? The LMS/Tobira backend does the signing. So for example in Tobira, we would probably have the API return already signed links. When the frontend requests all videos (with thumbnails) from a series, then the backend would just respond with a list of signed URLs to those thumbnails.

Don't get me wrong: I agree. The LMS/Tobira should care about this, but I think this is not terribly important for this discussion as this is just something every single app needs to care about. No coordination is necessary between the LMS teams.

[Hufschmidt]

You are totally right.
That is also how it works with Stream-Security, where the LMS can request all publications to already be (pre-)signed.

[Hufschmidt]

Adding as an additional comment as this might require a separate discussion:

Having read the original PR, one of the intentions behind the SFA implementation seems to be better support for using existing OpenCast ACLs to secure its static files, whereas Stream-Security instead delegates Access-Control to the external system (eg. LMS/ILIAS).

That means the SFA can be implemented in two ways:

Adhere to OpenCast ACLs

For this to work there needs to be:

• A mapping between LMS/ILIAS accounts/sessions and OpenCast users/roles
• The LMS/ILIAS needs to keep OpenCast ACLs in sync with its own permissions (eg. ILIAS Course-Member <-> OpenCast Read Permission for Video for user)

The former is already true for the ILIAS Plugin, but to my knowledge the later is only done for Course-Admin <-> OpenCast Cut Video/ Edit Metadata and could incure frequent changes to OpenCast Video ACLs depending on course-member fluctuations.
Additionally there might be videos that are available to all users logged into the LMS/ILIAS but not public per se, which would probably require special ACL handling eg. assinging Read Permission to ROLE_USER instead of specifiy ROLE_USER_<id>.

Ignore OpenCast ACLs

This would effectively make this work exactly like Stream-Security and probably go against the design goal of SFA.

Personal Assesment in regards to LMS integration

For embedding OpenCast videos into an LMS like ILIAS the Stream-Security seems to be the better option, because it allows Access-Control to be solely manged by ILIAS which already comes with a really flexible Role-Based-Access-Control system.
Additionally the same video/series might be embedded at different locations/courses in ILIAS, for different groups of users and thus permissions, making syncing ACLs with OpenCast probably a whole lot more complex.

[KatrinIhler]

Not done reading this thread, just wanted to say quickly that #5056 (mentioned in Lukas' description above) kind of attempts to make use of the best of both worlds: Keep SFA the way it is, making use of Opencast's existing ACL system, but allow an LMS to override that with special roles that don't have to be written into the ACLs.

[oellers]

Discussion: Multiple somewhat trusted external applications as jwt providers (trust management)

Use case
Let's say an Opencast instance is connected to multiple somewhat trusted external applications (which then are jwt providers), e.g. a LMS and Tobira.

Question for comprehension
If a somewhat trusted external application is in control of which videos are accessible, this might be a flaw. Basically this might look like handing a universal key to all videos stored in an opencast instance to an external application at first sight. What about private videos that were uploaded to the same opencast instance, e.g. from a different trusted external application?

Auth data constraints to limit scopes of authorization

I think there should be a way to limit and validate the issued jwt of somewhat trusted external applications, for example, via constraints / access rules for these jwt providers (maybe based on opencast ACL), similar to how jwt-based auth in opencast works.

Example
A somewhat trusted external application should only be able to grant access within its boundaries and therefore only be able to issue valid jwts within its scope, e.g., by enforcing constraints on the auth data that is received by opencast (limiting the roles granted, limiting scopes to specific video episodes or series in opencast, ...). Opencast should somehow be able to set and verify said boundaries for jwt providers. At the same time, this means that opencast need to receive scope-related data that allows it to decide the boundaries.

Difference between JWT-based Authentication / Authorization (OIDC) in Opencast

The difference between the usual jwt authentication / authorization setup is that we do not connect trusted identity providers providing and ensuring auth data to opencast but rather multiple somewhat trusted external applications. Do we trust them as much as, e.g., federated identity providers?

Edit:
- Adjusted term "frontend" to "external applications" as suggested by Lukas

[LukasKalbertodt]

Mhhh that's an interesting point. I wonder how common it is that organizations cannot trust their external applications (I will use that term instead of "frontend" here, to avoid some confusion, as LMS and Tobira also have backends) fully with all of Opencast's videos. I don't think such a system of restricting scope per external application is a bad idea, with the main disadvantage being complexity of course. I wonder if this can be added easily later after having decided on a simpler system first.

I can't say more about this topic as I have no experience with this usage scenario.

[Hufschmidt]

With Stream-Security you can define multiple token secrets and link those secrets with an url-pattern, see minimal example.

Something similar should work for JWT secrets. This way one external application cannot sign urls for video from another external-application assuming they are served from different domains, channels and/or organisations. But this would increase complexity both for configuration as well as implementation...

[oellers]

With Stream-Security you can define multiple token secrets and link those secrets with an url-pattern

This might be tough for defining restrictions to a user-base or based on the external application, series, episode, metadata but should work with channels (if I get that correctly).

I wonder how common it is that organizations cannot trust their external applications

Use cases: SaaS / Third-party Hosting
It might be the case that external applications are not maintained by the same organization (unit). Admins might want to grant externally / third-party hosted applications limited access to video resources within an opencast instance. But do you want to trust external sys-admins (e.g. SaaS environments)? Another example are logical units that use the same opencast instance but should not be able to access videos vice-verca or you might want to limit external applications to read-only (and you do not want to allow the upload of new videos). Limiting access of external applications would be a great addition to follow up on later.

This topic might be considered for the setup of trusted external applications (jwks, shared secret) that need to be done somewhere in opencast.

Claim constraints & Role mapping rules
Opencast has a concept of "claim constraints", where you can define rules that need to be fulfilled for a jwt to be valid, e.g., forcing usernames to contain a specific scope <value>['username'].asString() matches '.*@example\.org'</value>. Although, this would only validate contents of a jwt to some extent, e.g., limiting roles a jwt provider can grant. Taking opencast ACLs into account, this could allow to prohibit external applications from granting access to private resources of a user (as you cannot forge the user id) if such constraints are in place, therefore limiting the access on a user-basis. Role mappings could allow further restrictions, e.g. on an application-basis (<value>['domain'] != null ? 'ROLE_JWT_ORG_' + ['domain'].asString() + '_MEMBER' : null</value>)

If claim constraints and role mappings can be defined provider-specific, admins could restrict the roles that might be granted by the external application.

Limitations

• Requires that opencast acl needs to be taken into account
• Granular access scopes, e.g., based on the token issuer id (external application jwt provider), to grant access on a series-, episode-, metadata-, channel-basis or with advanced acl is not yet part of the concept (rule-based restrictions of external applications that cannot be stated as such a jwt constraint or via role mapping)
• The example above would imply that the same user does not want to access their own private video in the context of that different external application as well, e.g. limiting applications intentionally to a specific user-basis for this use case example
• ACL & User Ids: Also, we need to be aware of the fact that different applications might provide different user identifiers for the same user based on their environement (ROLE_USER_x vs. ROLE_USER_y), e.g. with targeted ids (OIDC pairwise sub, SAML pairwise-id) [though this might be more of an issue for external applications]

[LukasKalbertodt]

Quick note: currently, Tobira requires full trust (a ROLE_ADMIN account) anyway. And the same is true for many if not all LMS plugins, I think? That is not to say the ideas mentioned in this thread are useless - they are not. Just some information for completeness.

[geichelberger]

Cloudflare's approach to using JWTs for stream security is an applicable solution. One interesting detail is in Step 3, where they describe how the player or files can be secured using the same JWT token, which should fit our current URL schema (example below). Additionally, using JWTs as part of the request allows a web server to validate tokens and grant access to files without communicating with Opencast. For Tobira, this means that even if Opencast is offline, it can still generate valid JWTs that a web server can validate and allow access to the files.

https://developers.cloudflare.com/stream/viewing-videos/securing-your-stream/

Public:
https://develop.opencast.org/play/ID-video

Secured:
https://develop.opencast.org/play/eyJhbGciOiJSUzI1NiIsImtpZCI6ImNkYzkzNTk4MmY4MDc1ZjJlZjk2MTA2ZDg1ZmNkODM4In0.eyJraWQiOiJjZGM5MzU5ODJmODA3NWYyZWY5NjEwNmQ4NWZjZDgzOCIsImV4cCI6IjE2MjE4ODk2NTciLCJuYmYiOiIxNjIxODgyNDU3In0.iHGMvwOh2-SuqUG7kp2GeLXyKvMavP-I2rYCni9odNwms7imW429bM2tKs3G9INms8gSc7fzm8hNEYWOhGHWRBaaCs3U9H4DRWaFOvn0sJWLBitGuF_YaZM5O6fqJPTAwhgFKdikyk9zVzHrIJ0PfBL0NsTgwDxLkJjEAEULQJpiQU1DNm0w5ctasdbw77YtDwdZ01g924Dm6jIsWolW0Ic0AevCLyVdg501Ki9hSF7kYST0egcll47jmoMMni7ujQCJI1XEAOas32DdjnMvU8vXrYbaHk1m1oXlm319rDYghOHed9kr293KM7ivtZNlhYceSzOpyAmqNFS7mearyQ

Static files:
https://develop.opencast.org/static/mh_default_org/engage-player/<ID or JWT>/b900-3850-48bb-ad4e-50d2a978f1e5/Lavender_-_17156.mp4

[LukasKalbertodt]

That's indeed an interesting resource.

For Tobira, this means that even if Opencast is offline, it can still generate valid JWTs that a web server can validate and allow access to the files.

Can you point to a web server that can do that? Because I agree: it would be really nice to continue serving files even if OC is offline. Do you have any experience with that? Like, is there a widely used nginx plugin for example? If so, we should probably come up with a scheme that can work with that.

[KatrinIhler]

Additionally, using JWTs as part of the request allows a web server to validate tokens and grant access to files without communicating with Opencast.

This would indeed be a massive advantage, since using external file servers with SFP is currently, uh, problematic. 😅

[ferishili]

Technical Analysis for ILIAS:

Let's say we have the ILIAS as our LMS system, and we are using Opencast:

Current way of authentication/authorization:

• It appears that the most common way of performing authentication between ILIAS and Opencast is via the external systems like Shibboleth or LDAP, and they are working as expected.
• In order to authorize access to a video, it appears that the only way is via signing the (player/download) link when accessing a specific video/content.
• The permission management and other role related stuff is handled by ILIAS itself, and it seems to be working as expected.
• Neither the event nor the series in opencast would get course related ACLs!
• The ACLs are user-based (which is handled by external systems mentioned above), in addition to that it is possible to pass pre-defined ACLs like ROLE_ADMIN etc.
• The LTI auth was never implemented and never been used before.
• The Static Secure Files option has to be deactivated at all time when using ILIAS + Opencast, due to accessing the content directly!

The danger zone

• As explained above, the Static Secure Files option is always deactivated, therefore everything is accessible when one has the right url to access to!
• Even if you activate the link signing method, it could not fulfill the proper security measures and it has some flaws.
• Basically, ILIAS + Opencast means, an Opencast with less security layers as ILIAS claims to handle most of the permissions and roles management.

LTI vs JWT

Implementing custom LTI launches in ILIAS (like in Moodle) is almost impossible and the way of performing LTI launch calls is going to be banned by almost all browsers, therefore the first best and feasible option is to use is JWT. However, using that, requires some missing points/features, which, if I am not mistaken, are under constructions.

What is missing/what is needed

• Using JWT to fulfill the authorization part, but it has to be in close contact with those authentication systems, in order to pick up the roles and provide the claims etc. (the most important feature which is not there yet!)
• In ILIAS we only need to get the JWT token once, and attach it to every content url call which is going to be accessed/used.
• Every request coming to opencast must contain that jwtToken query parameter, otherwise, rejected! (this is the basic logic)
• Nice to have would be to somehow grant permission to the external apps (LMS) to generate those tokens by themselves. This way, they could also provide dynamic claims like the current course ref_id, etc.

[LukasKalbertodt]

Nice to have would be to somehow grant permission to the external apps (LMS) to generate those tokens by themselves.

I think this is the way to go. Tobira already does that. Asking Opencast to generate JWTs is quite a bit of overhead and luckily JWT was designed with that in mind: that external systems can generate JWTs on their own.

Using JWT to fulfill the authorization part, but it has to be in close contact with those authentication systems, in order to pick up the roles and provide the claims etc. (the most important feature which is not there yet!)

I'm not exactly sure what you mean by that. Can you elaborate? Opencast can already understand JWTs and use them for auth, though not yet in all situations we require for SFA.

In order to authorize access to a video, it appears that the only way is via signing the (player/download) link when accessing a specific video/content.

This also confuses me. Does Ilias perform some form of singing currently? Because as you said, currently SFA needs to be disabled, so I wonder what signing currently achieves?

[KatrinIhler]

This also confuses me. Does Ilias perform some form of singing currently? Because as you said, currently SFA needs to be disabled, so I wonder what signing currently achieves?

There might be some leftovers of the way stream security could be used (or abused) to grant access to a bigger resource like the player. That's currently not supported by standard Opencast components.

[LukasKalbertodt]

Good day everyone, sorry for not replying to this earlier.

Summary

I hope the following is a fair summary of the most important points mentioned.

• @Hufschmidt:
  • Single request authorization preferred over session-approach to keep serving files stateless, making multi node setups easier.
  • Using OC ACLs or not? Using ACLs requires more work but seems to be the original motivation behind SFA. Not using it would be more similar to stream security. For external applications, the stream-security-like approach is better suited, as one doesn't have to deal with ACL synchronization and all that stuff.
  • External apps should not try to encode stuff in OC's ACLs, but give access to a resource directly, to decouple auth from file serving. Therefore, implementing this as SFA Plugin makes most sense.
• @geichelberger: links how Cloudflare uses JWTs to solve this. Brings up a good point: come up with a solution that file servers can verify?
• @oellers: a way to restrict trust/scope of external applications. Important, but as far as I can tell, this doesn't need to be considered from the start. It can be added later.
• @ferishili: Ilias currently requires SFA to be disabled; LTI is not an option for Ilias; JWT is the way to go, but there are still features missing.

It seems very likely that two related PRs will be merged in the future (somewhat independently of this discussion). That's this PR which makes it possible to give access to resources directly by using special roles. The other PR will cause permissions of multiple JWTs to merge, which is also useful in a number of situations. I think with these PRs, it will be possible to solve this. However, we came here to find a standardized solution!

Next I will list all points that I feel like no one disagrees with and what it seems like we are moving towards. If you disagree, let us know, but otherwise we can use these as fix-points for further discussion.

• We want to use JWTs: it's a widely used standard, preferable over any custom solution.
• The external application generates these JWTs itself by having a secret key. I.e. we do not need to ask Opencast to provide JWTs/sign URLs.
• External applications want to give access to resources directly, not having to manage/change Opencast ACLs.
• We cannot rely on 3rd party cookies or any session to be present, requests need to be statelessly authorized.

Open questions

• Compatibility with existing static file servers?
  • Do people expect file serving to still work when OC is down? How hard of a requirement is that?
  • What are common plugins/ways to evaluate JWTs in nginx or other web servers? Is that even commonly done?
  • How to make sure that the schema we will agree on can work with those?
• How to give access to resources directly?
  • It seems like we want that, instead of dealing with OC ACLs. Which makes sense, as the external application has already performed the authorization.
  • But how? This PR is a somewhat elegant solution as it still uses OC's role-based authorization system while still allowing for fine-grained access.
  • However, it still uses ACLs and handling such requests would require more work to be performed than other approaches. It is also likely at odds with a system that also works for nginx-plugins (see previous point). Or maybe these disadvantages can be worked around?
• Also related to the previous points: should the JWT passed as query parameter (i.e. ?jwt=...) or as part of the path, e.g. where the video ID would usually be (as done by Cloudflare for example)?
• Is everyone aware of the added frontend complexity, i.e. dealing with 403 errors and refreshing tokens after a while? Is that fine for everyone?

More specific suggestions

With us having having discussed some basic facts, let me throw some additional, more concrete suggestions out there! Don't expect anything fancy though, the following is very basic, just using common JWT claims.

To grant permission to a static file managed by Opencast, the external application needs to create a signed JWT with the following fields (claims). This JWT is embedded in the URL somehow (either as query parameter or inside path).

• sub: e:d622b861-4264-4947-8db1-c754c5956433
  • A single letter prefix specifying the type of item.¹
  • The ID of the item (event, series, ...) that access is to be granted to, i.e. that the static file belongs to.²
• exp: expiration date/time of the JWT. Mandatory.³
• nbf: "not before" time/date. Optional.⁴

Example

(¹) Right now, all static files we are talking about only belong to events. But in the future, files could belong to a series or playlist (think series thumbnail). To anticipate future changes, I suggest adding this "type" prefix so that OC always knows what the JWT talks about. However, this might not be necessary since it can potentially be inferred from the request URL. Input on this would be appreciated.
(²) My assumption is that any static file always belongs to "one item" (e.g. event, series, ...), so that giving access to that item gives access to the file.
(³) It is common to restrict the time span that a JWT can be valid for. Opencast could have a configuration for that. But Opencast cannot know when the JWT is issued. So instead, OC could treat JWTs as invalid before exp - maxTime, as if nbf was set to that value.
(⁴) "Optional" means that the external application does not need to set it. OC should support this claim.

Additional fields can be added in the future, e.g. for restricting access based on IP ranges. We should always try to keep the JWT size as small as possible though. One noteworthy extension to this system would be to allow more than read access. That's not useful for static files, but for other uses like opening the Opencast Editor (where the user needs a session and write access to the event).

With this PR, the suggested system can already be used: by adjusting the role mappings, you can "convert" the sub field into a special role that gives the user access to that specific event/series. It might still be useful to write an SFA plugin (or something similar) to more directly implement the standard we will agree on in this discussion, to avoid everyone having to write the same role mapping.

---

I'm looking forward to more input on the open questions and my specific suggestion.

[oellers]

Thanks for your summary @LukasKalbertodt, getting the discussion back on track.

Just a few quick thoughts:

The external application generates these JWTs itself by having a secret key. I.e. we do not need to ask Opencast to provide JWTs/sign URLs.

So you opt for a symmetric, pre-shared-key approach and no certificate-based trust management (JWKS) approach? Is there a way to validate the jwt issuer then? Intention: Trying to reduce the risk of unwanted leaks / forwarding of the PSK to third parties or dealing with key rollovers

What are common plugins/ways to evaluate JWTs in nginx or other web servers? Is that even commonly done?

probably done by oauth / oidc modules

However, it still uses ACLs and handling such requests would require more work to be performed than other approaches. It is also likely at odds with a system that also works for nginx-plugins (see previous point). Or maybe these disadvantages can be worked around?

though, an acl-based approach might make it easier to implement restrictions for accepted roles from an issuer later on (this is just a guess)? (Although we would have to consider at a later stage anyway how exactly applications could/should be restricted/limited, what usage scenarios and best practice would be in this respect)

Is everyone aware of the added frontend complexity, i.e. dealing with 403 errors and refreshing tokens after a while? Is that fine for everyone?

could this be an issue with different time zones if the external application sets a time limit but the validation happens in opencast instance?

[LukasKalbertodt]

So you opt for a symmetric, pre-shared-key approach and no certificate-based trust management (JWKS) approach?

No, I would leave that to whoever sets this up. Either symmetric key or asymmetric key 🤷

could this be an issue with different time zones if the external application sets a time limit but the validation happens in opencast instance?

Apart from bugs: No. All code should treat the timestamps in JWT as UTC, so there shouldn't be timezone issues. The time of Opencast and the external application server might be slightly out of sync, but that's just a matter of a few seconds.

[KatrinIhler]

Do people expect file serving to still work when OC is down? How hard of a requirement is that?

At least for Ilias, serving files while OC is down isn't really a priority since when the External API is down, not much is happening anyway...

However, it still uses ACLs and handling such requests would require more work to be performed than other approaches. It is also likely at odds with a system that also works for nginx-plugins (see previous point). Or maybe these disadvantages can be worked around?

It doesn't really use ACLs, it uses roles. But I don't see why those roles (or whatever maps on them) couldn't also be interpreted by an Nginx plugin.

[KatrinIhler]

One thing that I feel is mostly missing from this discussion (and might influence this) is that the scenario of an LMS telling Opencast "Trust me, xy is allowed to do this" doesn't just apply to the serving of static files, but also for more complex scenarios like sending people over to the editor, the engage player or the annotation tool and allowing them to use those tools. I wonder if for these cases, attaching rights to a user session might not be easier or even necessary.

Also if we're not just talking about simple access to a resource, but want to differentiate between read and write rights or whether somebody is an annotate admin or simply allowed to annotate, it makes role mapping a lot more complex. In my naivety I imagined that we could simply encode the roles in the jwt token, but this probably makes the token much too big? (And then we have to think about whether/how to persists those rights and might want to take a look at the concept of anonymous users in Opencast that are granted specific roles by an external application, but that's probably going too far here...)

Sorry for the rambling, still trying to wrap my head around a few things. I'll come back once my thoughts are a bit more refined...

[LukasKalbertodt]

Regarding the Editor/Annotation Tool/apps... use case: yes, the user needs a session then. We can already do that via the /redirect/get endpoint. Tobira does it like that: it has a <form target="https://.../redirect/get"> with two hidden inputs (target and jwt). The button to open the editor submits that form, meaning that a POST request is sent to opencast, with a target URL (to redirect to) and a JWT. This creates a user session (i.e. a cookie) so that the user can use the app and all its requests are authenticated. This does not rely on third party cookies or anything like that, so this should be a fine solution.

What's missing, I think, is that permissions of these sessions stack properly. So if a user already has a session, the newly created session should merge with the existing one, giving the user the permissions of both sessions. And well, currently, Tobira does not communicate "the user can edit this event" to OC at all, which is obviously a big missing piece. But that's what will be solved by this discussion.

---

Regarding your point about multiple resources and and read/write/annotate: you are right, we should already consider all other uses of JWTs in OC, not just static file auth. It might be more difficult to make it work in nginx then but we have zero information on that yet, so whatever. So what do external applications encode in a JWT?

• Any permissions, not just read, but also write, annotate, ...
• Access to not only events, but also series, playlist, other items
• Access to more than one item
• Give custom roles (e.g. Studio does not need access to a resource, but the user must have ROLE_STUDIO)

I suppose there are many ways how one could encode that.

One could cram it all into one string claim, e.g. "oc": "ROLE_STUDIO,read+annotate:e:d622b861-4264-4947-8db1-c754c5956433". A comma separated list (arrays seem to be uncommon in JWTs?), where each item could be a role or giving specific access to a specific resource. In the latter case I pulled this syntax from thin air: action:kind:id with action as a +-separated list of different actions; kind either e for events, s for series, and so on; and id being the ID of the item in question. Its certainly terse, but keeping JWTs as small as possible is a good idea I think. One could even try to remove the ROLE_ prefix somehow.

Or we can have different claims, e.g. roles for raw roles; events, series and playlists for access to those items (where the allowed action(s) would be encoded like above).

I have very little opinion on the exact encoding, as long as it's reasonably flexible, extensible and doesn't bloat the JWT. Bonus points if it keeps the JWTs required to give access to static files small.

[geichelberger]

We should not mix authorized access to a single file or the single published media package with general user authentication and authorization for the application.

For delivering static files, the server (Opencast, nginx ...) does not need to know which user wants to access the server or which role the user has; it's enough to have something that grants you access.
Especially if we choose JWT, the token accessing static files differs from the token used for logging in or granting access to tools like Tobira.

[LukasKalbertodt]

You are right, but my comment was just about the shape of the JWT. It would be nice if the OC community can agree on something so that we can have a good default JWT config (with role mapping and such). For authorized file access, the JWT would just use "oc": "read:e:d622b861-4264-4947-8db1-c754c5956433" in the JWT, which does exactly that: just give access to a specific file, not fuzzing around with roles or the user or anything (just as you said).

I just don't see a point in using a completely different JWT shape (i.e. different claims) for one use case than for the other. That would just make the default JWT config/role mapping more complicated. The only reason I could see is: if we want nginx to understand the JWT to do the auth-check for us, then maybe we are somewhat restricted there. And then I can imagine using two different "systems".

[LukasKalbertodt]

For everyone subscribed to this discussion: I opened this PR with a proposal on how to proceed our JWT journey, as well as a specific proposal for how JWT claims should be used in the Opencast context. Please comment on that PR. I also hope to talk to many of you in person tomorrow.