Contributed authentication modules
The contributed authentication modules are available at http://www.squid-cache.org/related-software.html. At the time of writing, there is a RADIUS authenticator, a modification of the standard LDAP authenticator for non-anonymous servers, and a patch which supports static and dynamic LDAP group look-ups.
How Squid processes authentication
Squid uses sub-processes to process authentication requests to avoid being blocked by slow connections. The authentication sub-processes are connected to Squid by standard Unix pipes and Squid communicates with them via
stdout. The sub-process responds with "OK" or "ERR", depending on the success of the authentication.
Because every request must be authenticated, Squid caches the name/password pairs along with the results from successful authentications for a configurable number of seconds. This enables Squid to send requests for each item on a page, yet require only one authentication from the user's client.
Because of the cache, it is impractical for multiple users to share a login name. Squid uses
splay trees to handle the internal cache; these don't respond well to duplicate keys.
Caveats and gotchas
Authentication headers are consumed by the first proxy that requires them, and sometimes aren't passed on by proxies that don't need them.
The user authentication, ACL, reverses the usual ACL logic.
http_access allow localusersacts as if it read
http_access deny !localusers.
Access control lists have an implicit last line which reverses the rule of the last explicit line.
Now the boss is off your neck and your proxy authentication is working -- go grab yourself a drink and put your feet up. Unless he's after you to do the next job....
RFC 2617 "HTTP Authentication: Basic and Digest Access Authentication"
Jennifer Vesperman is the author of Essential CVS. She writes for the O'Reilly Network, the Linux Documentation Project, and occasionally Linux.Com.
Return to the Linux DevCenter.