jstarpl
commented
9 months ago Stable API & Users/Operators
I guess technically, what we would want is OpenID Connect since that would provide us with an "ID Token" JWT containing user profile information. Microsoft produces the "ID token" with a claim of "roles", okta returns a claim of "groups", both seem to be an array of strings. I suppose we could make which claim to use configurable.
I'm not sure if there's a standardized way of providing a list of other installations that the user can access through SSO. I suppose this could be done inside the ID Token as well, as a custom claim. It seems that at least Azure's Active Directory OpenID Connect implementation allows adding custom claims to the ID Token.
Persistent views
I suppose the "Persistent views" could use some sort of a URL search parameter secret. We would then have to ensure that they would have a "read-only" access then, since sniffing that search parameter would be trivial. This would basically allow one to have the Sofie without unauthorized people "peeking at it", but still be able to persist those secrets somewhere so that, for example, the Studio baseline can start renderers of these views out on SDI.
Julusian
This has been opened to share some ideas on how this could be approached
Motivation
In some deployments of Sofie, it is required to exercise good network security practises. As Sofie is typically an important piece of any studio where it has been deployed, it can be necessary to have it hardened to protect against either malicious or curious users.
Current status
Some groundwork was laid to support authentication in #237, but this was never put into production and is likely full of holes by now.
Proposal
There are a few main areas that will need considering differently.
Peripheral Devices (eg playout-gateway)
For these we currently have a basic token based system in place. This will stop or make it hard for a PeripheralDevice to impersonate another.
To make this secure, we should reverse the generation of the token, so that you have to generate a token in core first, and give it to the device before running it for the first time.
Additionally, this would be good to expand to support certificates as well as tokens.
At the same time, It would be good to look at limiting the methods which a device is able to call, so that they only do things which makes sense for them (eg, playout-gateway shouldn't be able to call an ingest method)
Persistent views
Often in the studio or gallery, there will be a screen always showing the prompter or presenter screen.
To support these will need some system of persistent credentials which only allow access to the specific view they are supposed to be showing.
Stable API
I have not thought about this API.
As this is primarily a system to system api, it should be pretty easy to use an off the shelf approach for api authentication.
Users/Operators
I think this area becomes quite complex to handle, as every environment will want something different. Company A might want to use LDAP, and Company B want to use Google. Building support for everything into Sofie will introduce a lot of complexity that could be done elsewhere. I think it is important that we keep the scope small, and support running with either one provider or with user authentication disabled
I propose that we make Sofie be able to talk to a generic OAuth provider. I don't know if OAuth is the best fit, I am open to other suggestions. If your provider needs something different/special, it could be approached by making a small application to translate that system to oauth. I don't know how user permissions fit into OAuth, but we will need the provider to report the permissions/access of a user.
This should give a pretty compatible and flexible system, pushing the burden of supporting each provider into their own small projects.
Additionally, with the current architecture, it is recommended to have one Studio per Sofie installation. This means that each installation has its own domain/subdomain, that users must remember and navigate to manually. It would be ideal if there was a service that Sofie could use to do 'installation switching'. I am envisioning something like the account switching you see with google, with either a dropdown menu showing other installations you have permissions to, or a link which takes you to a page which shows them all.
This switching service will rely on the OAuth provider reporting what servers a user is allowed to access, and will facilitate redirecting the browser to the correct sofie url.
The result of this will be that users can go to
https://sofie.example.com, and once authenticated they will be able to choose which Sofie they want to control, and be redirected there. And then easily switch to another installation, without needing to remember anything other than the 'home' url.Internal isolation
Internally, some parts of Sofie are written to ensure good isolation of concerns, and thinking about data ownership. Other areas are less good (eg the settings ui).
Some work will be needed to ensure that user levels are possible and are implemented correctly.
Request For Comment
This is solely my own thoughts, with no investigation into practicality of anything. I am open to suggestions on anything, and I am not aware of any plans to implement any of this currently.