Authentication

[kashyap2108]

No description provided.

[bgentry]

Not as of today. This is made clear in the docs but should be clearer in the readme. Recommendation is to either run it on a private network or front it with a zero trust auth gateway / reverse proxy setup.

We've talked about adding built-in support for CloudFlare Access as an auth option because that would be easy to do. I'm not sure we'll want to put a lot else in the main codebase though, because #107 would allow whatever auth schemes you can put in front of an http.Handler.

[cinemast]

Meanwhile, would you accept an PR that adds an optional basic-auth interceptor? This should be failry straigtforward to implement and would require only one or two additional ENV / config-parameters. I know the #107 is more elegant and flexible, but I guess for most people simple Basic Auth would be enough.

[bgentry]

Yes I think some built in auth options would be fine. Maybe @brandur has thoughts on how these would be structured?

[brandur]

@cinemast Can you talk about what your infrastructure setup would look like were River UI to add basic auth?

The main thing I'd worry about is that we add an auth layer, but only fake security because there's no out of the box encryption. So your user/pass is passed as plaintext and so trivially easy to steal that you may as well not have it, and we shouldn't provide it because some people might not understand this nuance and leave themselves accidentally vulnerable.

The only legitimate set up I can think of for this is something like Heroku where you have a router that handles encryption and an encrypted connection to a hosted node. But if you're on anything else where you're running your own reverse proxy anyway, you may as well just configure basic auth at the proxy level along with proper encryption (e.g. Nginx).

[cinemast]

That is exactly the use case yes, having it behind a loadbalancer that handles TLS/Let's encrypt setup but does not support Basic Auth out of the box.

e.g. Hetzner Loadbalancer is exactly that and what we are using.

Alternatively one can always throw Caddy in front of it of course, which offers TLS + Basic Auth, but this requires an additional container service which would otherwise not be necessary.

Totally agree that basic-auth without TLS is totally useless.

[travisby]

In our case, we plan to run the river UI in kubernetes with istio in front of it to handle TLS.

If the UI gets broken out from its main and into something like an http.Handler interface, I'd love to wrap it in the auth0 SDK/middleware to provide an oauth scope/login in front of it.

Until then, I think I need to run it adhoc from my local machine when I need it!

[brandur]

Got it. Okay, thanks — that makes sense.

[travisby]

(Actually, great idea with the "just run nginx in front of it". I might take that approach, I bet there's a simple auth0 plugin for that. And now it's just two containers in one pod, rather than one pod directly. Not a big deal!)

[brandur]

Yeah, Nginx would work for a lot use cases. Pretty easy to set up nowadays and a healthy ecosystem of plugins for things like encryption and auth.

[brandur]

That said, hopefully we'll have the http.Handler thing working sooner rather than later.

[cinemast]

Could we have #113 in the meantime? It would really simplify things a lot on my end.

[brandur]

Yes I think we can do that. I'll review it soon.

[bgentry]

As of v0.5.0, River UI can now be embedded as an http.Handler into any Go application. This means you can layer whatever authentication middleware in front of it that you'd like.

We will probably still move forward on #113 or other limited authentication options to make it easier to run as a standalone app, but given the wide variety of auth options out there our best advice is probably going to be that you should use the handler option to wrap the UI with your own middleware.

Check out the blog post to learn more: https://riverqueue.com/blog/river-ui-module-http-handler