I’m a little confused what you mean by ‘some form of authentication’. Do you want somebody to have to launch OHIF via Open OnDemand and then authenticate against it again? Or are you worried about somebody launching it and then other people being able to access their instance somehow?
If the latter, there are a variety of easy ways to address that by how you configure your app to launch. Open OnDemand inherently doesn’t do anything with security - it relies on underlying system processes, be them cgroup permissions, or containers or whatever.
I’ve used this in the past - a very simple proxy that you put in front of the app. Though with this scheme there’s a lot of fancy footwork you need to do to make it really secure. In this project I used a couple libraries to setup tensorboard in a network namespace with this proxy as the only entrypoint to that namespace - i.e., so nobody can actually connect to the actual application without supplying credentials. If you boot the app up without a network namespace, folks will be able to connect to it without any authentication.
Also note that this is python files was not written by me and does have a GNU license attached to it if you happen to copy it.
Unfortunately I don’t recall who made it initially and the license doesn’t actually seem to attribute it to any author…
What I mean is that currently if you launch any web server to ‘serve’ the PWA, any user on the cluster can connect to it. I would like (just like for rstudio or jupyter) that there is some form of authentication between the OOD frontend and the actual ‘app’, either a token/password or something being shared.
The difference with rstudio or jupyter is that this PWA has no security model of its own. No support for authentication.
Yes, that’s a possible solution but as you already point our rather complex with the network namespace. I was rooting for simply pushing a cookie/header/param and letting some webserver deal with it.
