CloudFlare Zero Trust authentication

[ghost]

This PR adds support for CloudFlare Zero Trust authentication

• The keys are rotated every 7 days, so I'm not storing them
• In case of error, I'm showing the authentication screen without the input and the submit
• The email already comes in the token and we are using it as display name

[josevalim]

Hi @cristineguadelupe!

Just to recap, I think API wise there are two levels:

1. Livebook.ZTA

2. The plug and configuration API which is exclusive to Livebook

Livebook.ZTA will be a collection of modules for each provider. So for example, we will have Livebook.ZTA.Cloudflare, which we will mount in our supervision tree:

{Livebook.ZTA.Cloudflare, name: MyLivebookZTA, other: ..., options: ...}

We will add this to our supervision tree based on the value of LIVEBOOK_IDENTITY_PROVIDER.

Then LivebookWeb.UserPlug will check if LIVEBOOK_IDENTITY_PROVIDER and act accordingly. If "cookies", same as today, if "cloudflare", you will call Livebook.ZTA.Cloudflare.authenticate(MyLivebookZTA, conn) which will return :ok or :error.

In other words, Livebook.ZTA will contain the service and the authentication/request APIs. The plug, application environment, are part of Livebook.

[josevalim]

Two nitpicks and ship it!

[github-actions]

Uffizzi Preview deployment-29059 was deleted.

[wojtekmach]

Our GenServer stores things in ets, but we never access them in this function, in the caller. Thus I believe ets is an overkill and we might as well store things in server state. To take full advantage of ets and avoid a single genserver bottleneck, I believe we want something like this:

def authenticate(name, conn) do
  token = Plug.Conn.get_req_header(conn, @assertion)
  do_authenticate(name, token) || GenServer.call(name, {:authenticate, token})
end

where both do_authenticate and handle_call({:authenticate fetches things from ets.

[josevalim]

Good find, added to #1941. Using ets also means the table has to be named, which means we need to require the :name option.