I’ve been searching for a way to serve Jupyter Notebooks to small groups from a private server.
Based on the responses I got from this question, it doesn’t appear that there are any solutions that allow authentication for users that don’t have an OS account.
I’m curious why this is. Is it because there hasn’t been enough demand for such a thing to warrant anyone working on it, or is there a fundamental aspect of Jupyter that requires system users only?
I’m willing to work on developing something new to meet this need, but I don’t want to put effort into something only to find out that it was impossible from the get-go.
It is absolutely not required to use system users with JupyterHub in general. System users are a requirement of some spawners (including the default and systemdspawner used in the-littlest-jupyterhub) and some Authenticators (include default and NativeAuth used in the-littlest-jupyterhub). So while TLJH makes choices that require system users, JupyterHub itself does not. TLJH is a “distribution” of JupyterHub that makes a lot of choices for you to simplify deployment, but they are far from the only choices you can make when deploying JupyterHub yourself.
The Authenticator needs some way to identify users. JupyterHub doesn’t care how. Authenticating with external services such as OAuth or LDAP do not need local accounts, while authenticating with the local PAM service does, for example.
The Spawner needs some way to launch servers on behalf of users. Like the Authenticator, JupyterHub doesn’t care how. To a first approximation, this means that container-based spawners (e.g. DockerSpawner or KubeSpawner) do not need system users, but local process spawners (including the default and systemd) do need system users because they launch processes as users using setuid or sudo or some such.
So one common and simple configuration that has no requirement for system users is OAuthenticator + DockerSpawner because the user accounts live somewhere else (GitHub, Google, etc.) and docker containers are used for isolation instead of system user accounts. This is what I typically use for small demos/workshops, etc.
It certainly can be on the server, but for oauth you’d need to start an oauth server. I’d say only use OAuthenticator if you want your users to login with their GitHub / Google / keycloak / etc. accounts.
In both of these cases, the question is: who are your users and do they have any existing accounts with some existing system that can serve as an identity provider? If so, then using an Authenticator that hooks up to that identity provider is the simplest way to deploy (be it LDAP or OAuth, etc.). If not, then you need to create accounts yourself. In that case, the simplest is local system users with PAM. If, for some reason, that’s not acceptable to you, you can use nativeauthenticator to manage user accounts in a password database (much like PAM, but a jupyterhub-owned password database, rather than the system one).
The users won’t have existing accounts anywhere. At least, we can’t rely on that being true, so we’ll have to create their accounts ourselves. We’re not allowed to create system users on the server, though, so we can’t use PAM or the nativeauthenticator.
Sorry, I was wrong in the original post. nativeauthenticator does not require system users. It’s only the spawner in tljh that requires system users. So that should work fine for you.