Project

General

Profile

Actions

Feature #2703

closed

Forward authenticated user to proxied requests

Added by flynn almost 9 years ago. Updated over 7 years ago.

Status:
Fixed
Priority:
Normal
Category:
mod_proxy
Target version:
ASK QUESTIONS IN Forums:

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

Actions #1

Updated by stbuehler almost 9 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)

Actions #2

Updated by gstrauss over 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.

Actions #3

Updated by gstrauss over 8 years ago

  • Category set to mod_proxy
Actions #4

Updated by gstrauss over 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?

Actions #5

Updated by gstrauss over 7 years ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100
Actions

Also available in: Atom