RFC: Identifying users/operators

[Julusian]

About Me

This RFC is posted on behalf of the BBC.

Use Case

We would like to be able to identify the user/operator of the current browser session, so that we can provide a more tailored experience and a more granular permissions model than is possible today.

Primarily we intend to use this so that an operator can have exclusive access to perform playout operations on the activated playlist (follow up RFC incoming)

This RFC is limited to Sofie identifying users/operators and including this information in appropriate logging, and a basic display in the UI.

Proposal

This builds on RFC: Header based auth , and is intended to be an optional extension to this.

When enabled, the HTTP auth header will instead contain a JWT for an operator/user. The current permissions levels should be contained as a field in this JWT.

I am leaning towards using the terminology ‘operator’ rather than ‘user’, because in some cases this could be using credentials tied to a machine rather than a person, and operator feels a bit more neutral on whether it is a person or machine. I am using the terms interchangeably in this RFC. I also think that operator helps clarify that it isnt tied to a user system built into sofie, but that these are semi-abstract external entities.

The Sofie UI should show some basic information about the current user in the right side of the navbar (in some views), for easy identification of the current user.

To achieve this, Sofie will need to be able to make http requests to a simple service which will provide additional information about a session (using the id/token from the header). This will provide a user facing name for the operator, and in the future could be used to verify that a session is still valid (if the user logs out, our websocket could remain open. sofie could use this endpoint to check the session is valid and close the connection if not. This is a thought for the future, not in scope of this RFC)

The exact structure/syntax of this endpoint and header has not been explored, I expect there could be an existing standard that we should use for this, or we might need to invent something. Maybe a portion of OIDC would fit what we want here.

The header challenge

The other big challenge I see here is what header to use. The sockjs used by meteor only passes through a handful of headers with well defined uses https://github.com/sockjs/sockjs-node/blob/a43ed3bd25c9df16e18c681a678d5bc47b0758a1/lib/session.js#L137-L150 . For the current header auth we used the dnt header, which is ugly but it works.

If we want to use a proper name, this presents the challenge of how to get those headers through sockjs into meteor.

I see a few possible options that could be investigated:

1. Setup a new DDP server inside of meteor, using an implementation which preserves all headers. We can then either:
   a) proxy the traffic to the builtin ddp server, injecting an extra parameter to method calls for our values, or maybe an ‘init’ method call. This will be suboptimal, due to the proxying
   b) hook into meteor internals or use our own implementation of the method executions/publications
   I think both these options raise the question of whether we should ditch the meteor http server entirely; we are already using our own koa router for any http requests.
2. We could look into modifying the meteor ddp packages to support this, but I suspect that will end up with a complex mess of overrides that will make updating meteor very hard and brittle.
3. Replace DDP entirely? This has been proposed already, but as no decision has been reached on what to use instead, I think that it would be best to avoid this for now.

Personally I think the best approach would be to do 1b for this, likely including the bit about bypassing meteor for http. It is likely more work than 2, but feels like the cleanest solution and continues us in the direction of gradually removing meteor rather than making our reliance on it deeper.

Depending on the effort required, we may not want to do this portion, but I think it good to have a plan in case it becomes necessary.

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