Forward Authenticated User

I am attaching a patch for 3.0.x versions (I will forward port if there
is interest and change recommendations). This patch adds a new option to
Squid that allows it to forward the current authenticated user to the
next proxy (or the HTTP server if that is what is wanted) via an HTTP
header.

The need for this option is originated by the usage of Kerberos
authentication on our installations and the usage of an external content
filter proxy (Dansguardian). By nature the Kerberos authentication
header sent by the browser to proxy is heavily encrypted and is designed
to be data to only be understood by the browser and the Squid proxy that
is doing the authentication. Basic installations of Dansguardian (oand
my other non ICAP content filters) is to chain Dansguardian before
Squid. The problem with this setup is that Dansguardian needs to know
the user before the request is sent to Squid to do checks before the
request is sent to Squid (for example, denying it filtering by URL).
Dansguardian is able to works in this configuration for other auth
methods like basic, and NTLM, because it is able to extract the user
from the respective auth headers, something it can not do from the
Kerberos encrypted header.

The solution to this problem is to switch the positions of Squid and
Dansguardian in the chain, forward from Squid the authenticated user to
Dansguardian (disabling caching on Squid in order to not cache
Dansguardian generated responses). If caching is needed a second Squid
could be added after Dansguardian

Browser -> Squid (no caching) -> Dansguardian -> Squid (optional) ->
Internet

Dansguardian is patched too in order to add an authentication plugin
able to understand the forwarded authenticated user. Currently my
Dansguardian patch is not able to remove the header from the request,
something that must be done for privacy reasons when not using the
second optional Squid (if authenticated user forwarding is not enabled
on it the header is removed)

I think ICAP could be the ideal solution for this problem, when Squid is
able to call ICAP services at postcache stages.

TODO: the user is forwarded, Dansguardian uses it, but the other Squids
on the chain are not able to use acls using that user, for them the
request is unauthenticated, it is interesting to add the capability to
use that user on that other Squid instances for example to be able to
use different tcp_outgoing_address using auth based acls

This solution has been working for near month on a production site with
more than 100 simultaneous users without problems to the present day

Note: thanks to rousskov ant squiddev IRC channel for the help and
recommendations