RFC: Header based auth

[Julusian]

About Me

This RFC is posted by SuperFly.tv on behalf of the BBC.

Use Case

We want to be able to run Sofie to be accessible over untrusted networks. This can include private networks, where we want to be sure that a malicious actor who has acquired network access cannot access Sofie.

We want Sofie to enforce the user levels as known in the ui in the url parameters. So that a user who should only be able to use playout in sofie cannot find their way into the settings and modify things.

We don’t want to rely on authentication being done inside of Sofie, we would like to link this to active directory for SSO, or some other schemes for gateways (perhaps certificates or authorization header based).

The exact process is going to be different for each organisation, and potentially for each type of client (user vs gateway), so the less that Sofie needs to know about it the better.

For now we intend to run Sofie with one studio per installation, so have not considered multi-studio cases.

Proposal

We propose that this should work by Sofie checking a header in http/ddp connections, to determine the permissions of a session. It is already recommended to run Sofie behind nginx or some other reverse proxy to add TLS to the connections, and this is a convenient way to perform authentication. 

It is widely documented on how to protect sites in these reverse proxies using you existing SSO scheme of choice, and adding headers as part of this is a common thing to do.

One option for this is that sofie could expect this proxy t check a specific header for a comma separated list of permissions. Eg studio,configure

View only users should have an empty header, any connections which should not be allowed access should be denied by the reverse proxy.

The exact list of these values is not concluded, but it will likely be derived from the current set of properties we use in the UI.

In the initial version, gateways will fall under a single ‘gateway’ level. In the future this should be broken up, but that is not in scope of this RFC.

This means that the reverse proxy is also making the decision about what a user/connection is allowed to do, leaving sofie to simply enforce the permissions.

Inside of Sofie, we have access to the connection headers in each of ddp methods, ddp subscriptions and http calls, so we can easily verify whether a call is allowed.

For client side mongo updates, this is a bit trickier, but with some fiddling of meteor internals, it is possible to do. This hack works in meteor 3.0.2, so shouldn't be a blocker to updating meteor.

To keep the UI in sync, a meteor method will be added for the ui to be able to retrieve the information about the user permissions. The intention here is that the ui should call this method each time the ddp connection reconnects, so that it can be sure it has an accurate view of the users permissions.

One limitation in this proposal is that there is no convenient way for sessions to expire. Once the ddp connection is open, it will retain the permissions until it is closed. For now we are happy to live with this limitation. If there is a need to terminate a session, making the reverse-proxy drop all its connections can handle this.

There is a draft PR which serves as a POC of proposal at bbc#11. This PR doesn't cover much, it was just to ensure that the proposal was viable and would work.

---

Additionally, to make implementing this easier, I would like to question whether anyone wants to keep around the existing user and auth system. This system has been only minimally maintained since it was implemented years ago, and as far as I’m aware has never been put into production. The UI implementation of this was removed in release52, and looking ahead to further removal of meteor, will need rewriting as it relies heavily on meteor’s builtin auth system.

All of these existing checks will need to be updated to consider the header auth too, so unless there is a reason to keep it, it would be preferable to remove the code instead of refactoring it.

Removing this is not a requirement, so if anyone has a reason to keep it then this point should be dropped from this RFC.

Process

The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.

• RFC created
• Sofie Team has evaluated the RFC
• A workshop has been planned
• RFC has been discussed in a workshop
• A conclusion has been reached, see comments in thread