Feature #2703
closedForward authenticated user to proxied requests
Description
The proxy module should forward the authenticated user (if lighttpd has detected one) in proxy requests through the REMOTE_USER http-header.
Other backends like fcgi/scgi/cgi already do that.
I did not find a way to add this header either with lua/mod_magnet or with the directive setenv.add-request-header.
So I'm supplying this simple patch (e.g. for usage with the coming buildbot version 0.9).
Apache has a similar feature, so lighttpd should have it too.
A notice in the wiki, that the REMOTE_USER http-header can only be trusted in secure environments, should be added.
Files
Updated by stbuehler over 8 years ago
- Target version changed from 1.4.39 to 1.4.x
The CGI environment includes the http headers in the HTTP_* namespace; outside this namespace the CGI variables have usually well-known semantics.
Adding a CGI environment variable into HTTP headers on the other hand isn't that obvious: as the headers send by a client are not confined to a "well-known" set, any name you choose could potentially conflict with a header sent by the client, so there is always a potential information loss if you overwrite the values.
Also you really need to make sure to always overwrite the value (i.e. delete first, then set if appropriate), otherwise the client could simply send it's own REMOTE_USER header and not authenticate otherwise.
I'm not convinced hard coding this logic for a single CGI variable is the correct way.
Maybe mod_magnet could offer a more flexible solution by making the request headers modifiable in lua; maybe mod_proxy could take a list of mappings of CGI vars -> HTTP header names (in this case we probably should first refactor CGI variable semantics into a common implementation for mod_*cgi, which would be a good idea anyway).
(Edit: btw, your patch is in "reverse" mode - it removes lines instead of adding them)
Updated by gstrauss about 8 years ago
I'd suggest extending the Forwarded HTTP Extension https://tools.ietf.org/html/rfc7239 with a (non-standard) extension parameter 'auth_user="$REMOTE_USER"', with $REMOTE_USER properly url-encoded, and including it only if a new config param proxy.forwarded-auth-user = "enabled". Since lighttpd mod_proxy is a reverse proxy, it might choose to always include the Forwarded header, or that might be a config param, too. If Forwarded header is not always included, then mod_proxy should probably at least check for and strip auth_user param off the final list entry in Forwarded.
Recipients of the Forwarded header would have to trust the immediate upstream server as well as the intermediate network (if the connection is not encrypted), and would need to take care to properly parse and look at the final list entry in Forwarded header to look for auth_user. (There might be multiple list entries if there were multiple proxies adding to Forwarded). Properly parsing Forwarded headers includes handling header line wrapping as well as concatenation of multiple instances of Forwarded: header. Proper handling is also necessary in mod_proxy.
Updated by gstrauss about 7 years ago
- Status changed from New to Patch Pending
- Target version changed from 1.4.x to 1.4.46
Large patch set pushed to lighttpd.net git personal/gstrauss/master branch. See DevelGit to obtain the code. Feedback appreciated.
This feature is experimental and subject to incompatible behavior changes.
Should param name be "auth_user" or "remote_user"? I used "remote_user" for now.
Should param "auth_type" be handled so that mod_auth can pass both AUTH_TYPE and REMOTE_USER?
Updated by gstrauss about 7 years ago
- Status changed from Patch Pending to Fixed
- % Done changed from 0 to 100
Applied in changeset b2e2d42c8385c7485167baf7014492d8e4d724d0.
Also available in: Atom