Add extra layer of security for publicly-facing Automaat instances

[JeanMertz]

An excellent point by @jurre (who has plenty of experience in this field).

The current authentication/authorization setup (#19, #21, #39) is not meant for public security (as mentioned in those issues, and as will be mentioned in the documentation).

However, RTFM is a thing, and insecure tools (such as Wordpress, MongoDB, etc) are exploited on a daily basis.

So, at some point, we probably want another layer of security that re-introduces the concepts built (and later removed/changed) in 411e8e2 and 5552179.

This would be an on-by-default "zero access without authentication" feature that can be disabled using a CLI flag for those running the tool within their organisation's internal network or behind a VPN (such as we are at Blendle), to make its usage more organisation friendly.

It should still be clearly documented that even with this feature, you'd be wise to not expose this tool to the public internet, but at least the default setup is a little bit more resistant against people not reading manuals or not understanding the power a tool like this holds.

[JeanMertz]

Some added thoughts:

This would work well with the "server capabilities" feature described in #38.

The client could then re-use most of what was built for #19 (comment), and simply show the login screen upfront instead of delayed when trying to run a secured task (which is how it works right now).

The biggest change required would be to refactor the auth token storage on the server, which is not meant for robust security right now. But that would be nice to do anyway, as it would benefit the current use-case of running Automaat behind a VPN as well, even if it has less impact in that situation.

[JeanMertz]

I still feel like this feature is a double-edged sword.

On the one hand, we'll never be able to make it as secure as third-party security providers can provide (of which there are many, including on all the big cloud providers). So if we add this layer, it would be "as secure as we think we can make it", but potentially not secure enough. This might then encourage people to use it as it's "good enough". Whereas, if we didn't have this security layer, and made it very explicit, you'd "force" people to look for good security elsewhere. Obviously, some people might still ignore that and host Automaat unsecured on the public internet.

Perhaps we can at least start by making Automaat listen on the local loopback address by default, and have it print a warning on startup when that value is changed, to urge people to make sure they setup is secured.

Another addition would be to require an explicit --public server flag to allow changing the bind address away from the loopback address.

That won't be the end-game, but it's better than what we have now, until we decide on the next step to take.

---

For reference, at Blendle we're using Google's Identity-Aware Proxy to secure our Automaat instance. This works well for us.