Add experimental support for letting application services proxy namespaces in the C-S and S-S API

[Johennes]

This is a stopgap towards https://github.com/element-hq/voip-internal/issues/641. It introduces a new configuration property io.element.proxy that allows application services to claim namespaces in the C-S and S-S API. For requests underneath a claimed namespace, Synapse first authorizes the request and then reverse-proxies it to the application services. For now, the only allowed namespace that can be claimed is rtc/livekit.

This pull request can be reviewed by commits.

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Code style is correct (run the linters)

[MadLittleMods]

allows application services to claim namespaces in the C-S and S-S API. For requests underneath a claimed namespace, Synapse first authorizes the request and then reverse-proxies it to the application services. For now, the only allowed namespace that can be claimed is rtc/livekit.

This sounds like something that should be handled by a Secure Border Gateway (SBG)

[Johennes]

Hm, is the SBG capable of verifying client access tokens and federation signatures?

[MadLittleMods]

Yes, see crates/matrix-sbg/src/annotations.rs for how this information is derived for each request and then some request.verified_requester() example usage. See this note for the federation side but it could be updated to handle it as well.

[Johennes]

Thanks for the pointers. This looks interesting but I think it may not be a good fit here. Our specific use case is we want to convert the endpoints that lk-jwt-service serves into regular C-S endpoints but still spare Synapse (and other homeservers) having to implement them. Instead, the idea is to run lk-jwt-service as an application service and letting it claim part of the C-S (and S-S) API. In other words, the interface being public and (in future) part of the AS spec is actually intentional.

[erikjohnston]

Note that the lk-jwt-service is FOSS and needs to work with FOSS Synapse, specifically it'll implement a specced MatrixRTC transport. The reason for having it separate is so that we don't have to have VoIP specific code in Synapse and can leave that to the VoIP team.

SBG is proprietary. It would potentially be useful if lk-jwt-service was also going to be private, but it's not

[MadLittleMods]

Our specific use case is we want to convert the endpoints that lk-jwt-service serves into regular C-S endpoints but still spare Synapse (and other homeservers) having to implement them

[...]

In other words, the interface being public and (in future) part of the AS spec is actually intentional.

Seems like the same sort of pattern that we use MAS for implementing the OAuth API and even serving the legacy Matrix auth API for compatibility.

Why is this new proxy pattern necessary compared to what we do for MAS?

[Johennes]

It is essentially the same pattern but going through the application service API in generalised form to make it easier to reuse by other homeservers (and future possibly other application services). I'm hoping to still write an MSC for this but haven't gotten around to it yet.