Using a remote runtime as a Livebook identity provider via RPC

[mbklein]

My plan is to have a Phoenix application running at https://myapp.example.edu/ and a (firewalled, VPN-access only) Livebook instance at https://myapp.example.edu:8080/ that will be used to do some maintenance/administrative tasks and experimentation within the main app's runtime via Remote Execution smart cells. From reading some other issues and discussions, it sounds like this isn't an uncommon use case.

The main application already has session-based authentication (derived from our institutional single sign-on, but that's not really important to this discussion). Since Livebook will be running on the same host but a different port, it's easy to surface the same session cookie in Livebook.

What I'd like to be able to do is configure Livebook with something like:

LIVEBOOK_IDENTITY_PROVIDER=rpc:<auth_node>:<auth_node_cookie>:MyApp.AuthModule.livebook_auth/1

To authenticate, Livebook could then

Node.set_cookie(auth_node, auth_node_cookie)
:erpc.call(auth_node, MyApp.AuthModule, :livebook_auth, [%Plug.Conn{<current_request>}])

to let the remote runtime look at the incoming request and decide whether the user should have Livebook access.

This would essentially make Livebook as secure (or not) as the remote runtime already is. Would this be a good candidate to add to Livebook core? I might put some time into implementing it either way, but it would be good to start out knowing whether it would be welcome as a PR.

[josevalim]

Unfortunately this sounds very niche for us to provide by default. If you already have firewall / VPN access, aren't they passing any tokens to the underlying application that we could use?

[mbklein]

👍 Successfully authed myself using a custom provider and my running webapp using that PR branch:

[jonatanklosko]

and Option 1 can support it by mounting an external volume into the container as (or within) the extensions folder.

You can also define a custom Dockerfile based on Livebook and copy the files into the image :)

[mbklein]

I just tried my custom auth module again with the ghcr.io/livebook-dev/livebook:edge Docker image, and I had to add one more thing to make it work. If my custom auth failed, Livebook rightly returned a 403. But on success, I was dropped back into token auth. I worked around it by updating the custom module's init/1 to disable token auth:

def init(init_arg) do
  Application.put_env(:livebook, :authentication_mode, :disabled)
  {:ok, init_arg}
end

Is this expected, or should token auth automatically be disabled by LIvebook when an alternate identity provider is configured?

Other than that (and even with that, if that's the interface), this is exactly what I needed. Thank you!

[jonatanklosko]

@mbklein this is expected. The identity is to filter user access to Livebook, but the Livebook auth is still as usual. In your case, if anybody that passes the custom authentication should have full access, you can set LIVEBOOK_TOKEN_ENABLED=false for the container.

To give more context, Livebook allows you to deploy apps and those can be public or password-protected. The apps are visible to anyone who can access the page, they don't need full Livebook access. So you could use ZTA to guard access to apps, but then still have a Livebook password for admin access.

[mbklein]

Thank you for the explanation. I still haven't delved into apps all that much, so I forgot about that whole side of the equation. This level of flexibility is great.