Implement support for authentication via Auth Proxy

[pborzenkov]

Auth Proxy allows to authenticate a user using an HTTP header provided
by an external authentication service. This provides a way to
authenticate users in miniflux using authentication schemes not
supported by miniflux itself (LDAP, non-Google OAuth2 providers, etc.)
and to implement SSO for multiple applications behind single
authentication service.

Auth Proxy header is checked for the '/' endpoint only, as the rest are
protected by the miniflux user/app sessions.

Closes #534

[fguillot]

Sorry for the delay, I will try to find some time to review your PR over the weekend.

[fguillot]

@pborzenkov What about using Auth Proxy for the API endpoints and URLs other than /?

With the actual implementation, if a non-authenticated user goes directly to a specific URL (for example /unread/entry/1234 ), it will be redirected to the login page instead of using Auth Proxy.

[pborzenkov]

Sorry for the delay. I was on vacation with no access to the Internet.

With the actual implementation, if a non-authenticated user goes directly to a specific URL (for example /unread/entry/1234 ), it will be redirected to the login page instead of using Auth Proxy.

Where it will be authenticated using Auth Proxy. This keeps the same behaviour as with other login methods (user/pass and OAuth). If this is something you are not happy with and would rather have Auth Proxy checks on all endpoints, I'll update the PR. I just wanted to keep consistent experience between different login methods.

[fguillot]

That seems to work fine for the web ui. What about the REST API?

The Grafana example cited in issue #534 seems to allow the Auth-Proxy for API access as well. Might be a nice to have.

I'm thinking about implementing an API tokens mechanism in the future instead of using the user password...

[pborzenkov]

That seems to work fine for the web ui. What about the REST API?

I was thinking about adding support to the REST API initially. But then what's the workflow is gonna be? When accessing miniflux via Web UI, a user might be redirected by a reverse proxy to an entity that actually authenticates it and this entity might be interactive (e.g. login via OpenID provider). Not sure how this can be implemented for API access.

And the API client can't set Auth proxy header by itself, as the header must be stripped by the reverse proxy (for security reasons).

So I can't really see how the Auth proxy workflow can be supported in the API. And I'm not really sure it's actually needed. If you're planning to add tokens, then Auth proxy for UI + tokens for API will work smoothly together: a user logs in via UI (authenticated via Auth proxy) and creates a token for API access.

[fguillot]

I think it's good enough for now. Let's merge :)