Add authenticated reverse proxy mechanism

[RubenVerborgh]

This pull request allows Solid server to act as a reverse proxy for backends, to which it passes authentication information (user and host).

This feature can be configured as follows:

{"authProxy":{"/my/path": "http://localhost:2345/app" } }

With the above configuration, a request to https://ruben.solid.server/my/path/to/something?x=y will be proxied to http://localhost:2345/app/to/something?x=y. The User header on the proxy request will be set to the currently logged-in user (or empty if none), and the Forwarded header will be set to host=ruben.solid.server. This enables the proxied server to serve content from that user on this specific host.

Other changes

In order to avoid confusion between the existing CORS proxy and new auth proxies, the proxy parameter has been deprecated and renamed to corsProxy.

Security considerations

Problem: Anyone can pretend to be authenticated by sending a request with the User and Forwarded headers to the proxied server directly (instead of going through the Solid server).

Possible mitigations:

• The proxied server should only trust the User and Forwarded headers if they are received through the Solid server.
• It is advised that the proxied server not be publicly visible, but instead only in the Solid server's own network.

[dmitrizagidulin]

The proxied server should only trust the User and Forwarded headers if they are received through the Solid server.

Is this meant on the network/firewall level? (As in, only solid server will be able to access the internal port that will be closed to the outside?)

Or are there other mechanisms we can use to have solid-server authenticate itself to the proxied service?

[dmitrizagidulin]

Nice :)

[RubenVerborgh]

Is this meant on the network/firewall level? (As in, only solid server will be able to access the internal port that will be closed to the outside?)

Indeed, on a network/firewall level. This is usually the case for reverse-proxied servers: they live in a private network, and the reverse proxy is their trusted gateway to the outside world.

Or are there other mechanisms we can use to have solid-server authenticate itself to the proxied service

There are; we could apply encryption etc. However, this would complicate things on both our side and the reverse proxy side—I think the most straightforward option is that the reverse proxy checks whether the Solid server initiated the connection (or that it is simply not accessible by other servers in the first place).

[dmitrizagidulin]

Looks good; nice work on this.
Let's add the new config params to the CHANGELOG section so we dont forget in the future, and it'll be ready to go.

[RubenVerborgh]

CHANGELOG entry prepared in #534.