Restricting who can view a stream

Hi Janusians,

I have a few questions concerning the nature of Janus and its Plugin infrastructure.

I’ve looked at the (source code of the) VideoRoom demo and I can’t figure out if Janus has any built-in capabilities to restrict who can watch a stream. Can anybody who knows a video room ID subscribe to the stream?

If Janus has no built-in mechanisms, how would I go about implementing them – on a high level?
Assuming I have a server running with user management, how would I make sure only certain users are allowed to view a stream?

I would assume I can hook into the WebRTC handshake procedure somewhere … but where?

Specifically, I’m trying to deploy Janus with the FTL-plugin from the Glimesh folks (GitHub - Glimesh/janus-ftl-plugin: A plugin for the Janus WebRTC gateway to enable relaying of audio/video streams utilizing Mixer's FTL (Faster-Than-Light) protocol.), which has about zero documentation.

To use it, I have a running instance of their whole Glimesh streaming platform, where I can generate a STREAM KEY (which doesn’t limit who can watch, just limits who can stream in a channel).

After that, it’s just “fire and forget”, i.e. I send an (OBS) stream to the configured server address and then anybody can subscribe to that feed if they know the channel id (room id)

Again, with regards to restricting viewers, would I implement this in Janus or in the FTL-plugin?

By default both Janus and plugins give a lot of freedom, since it’s all a matter of “how can we allow people to do as much as possible”. To limit watchers, I’d probably use a combination of a couple of features:

  1. force private IDs, so that you can create a subscription only if you join the room with a participant handle (no need to publish anything)
  2. use the ACL feature in the VideoRoom, so that you can only join a room if you provide a valid token

I can’t help on FTL as I don’t have any experience with it, sorry.

Of course, you can also more simply hide the Janus API behind a different protocol, which enforces the limitations you want. That way, an intermediate component can be the only one talking to Janus, thus limiting what users can do to what the intermediary decides should be possible. This is a common approach, and not sure if it’s what FTL does too.