feat(auth): support for forwarded auth provider

[ajgon]

What type of PR is this?

• feature

What this PR does / why we need it:

This PR introduces a new authentication provider, called "ForwardAuth". It's written with forward-authentication supporting reverse proxies (like nginx or traefik) and accomodanting authentication apps (like authelia, authentik and probably many more).

With this changes, if homebox is configured in one of Fw-Auth setups, it will automatically sign in (and register, depending on configuration) user forwarded by initial authentication backend, thus removing necessity of logging in twice.

This is done by special header (also configurable, by default Remote-Email) which tells homebox, that authentication was already be done, and it can trust that given email is already valid. Of course, a malicious user, my try to send this user, by themself trying to impersonate the real one - but in properly configured fw-auth setups it shouldn't be possible. Anyway, to avoid any mistakes, there is another configurable field, defining list of IPs which are allowed to be source of fw-auth traffic. By default it's empty, meaning every source is blacklisted - thus feature is disabled. This also protects installations which doesn't need this feature, to not accidentally expose themselves.

Which issue(s) this PR fixes:

Implements #270

Testing

I deployed updated code to my cluster, and tested everything with authelia.

Release Notes

- Support for forward-authentication applications like authelia.

[ajgon]

After I pushed this PR, I noticed there was another attempt before, but closed because of expected login providers refactor. Since this is (I assume) done, I think we can get back to the problem, and try to implement it again?

@verybadsoldier - I'm tagging you, if you have any input/opinion about this, since you are the author of the original one :)

[hay-kot]

I deployed updated code to my cluster, and tested everything with authelia.

Hey, this looks great! Since I don't have any infrastructure for running or testing this, I won't be able to merge it without any kind of automated testing.

What options do we have there for implementing automated testing in CI? Ideally, something that we can run locally would be great as well, but CI is definitely a requirement.

[seiferma]

@hay-kot Which types of tests do you have in mind? I am interested in the feature and willing to help.

I only had a quick look through the repository. To me, it looks like there are unit tests at the moment. Creating unit tests for the contributions should not be a big deal and I could create them if @ajgon would like to have support on this.

However, I assume that you are aiming for integration tests or even system tests based on your comment regarding test infrastructure. For integration tests, a mock of the authentication endpoint would be sufficient from my point of view. Though, there would be not much benefit from doing this compared to unit tests from my point of view.

Tests regarding compatibility with real authentication endpoints feel like system tests to me. We would have to spin up the application, a reverse proxy and the authentication endpoint. Of course, this is possible but before I start working on this, I would like to be sure that this is what you are aiming for.