[RFC] Configurable authentication helper requests

Hello,

    I would like to make proxy_auth helper request fields configurable
by adding a new request_format option to auth_param. Here is a sketch:

  auth_param basic program ...
  auth_param basic request_format "%username %password %myportname"

The actual %macro names in request_format should come from logformat
codes where available (and we can add new ones where needed). I used
more readable names for illustration purposes only.

This feature is needed for Squid admins that have to use different
internal authentication lookup algorithms(*) depending on various
transaction parameters. For example, they may need to use Digest helper
algorithm#1 for users coming to http_port#1 and Digest helper
algorithm#2 for users coming to http_port#2. Or, perhaps, Basic helper
algorithm#1 is for users with client SSL certificates signed by CA#1
while Basic helper algorithm#2 is for users with certificates signed by
CA#2. There are many variations on this theme.

Today, Squid supports only one authentication helper per authentication
scheme. The need for multiple helpers per scheme can sometimes be
supported by running several Squid instances, but parameters such as CA
name or IP ranges do not allow for that workaround (or the workaround
demands too many Squid instances to be practical).

AFAICT, the proposed feature is 100% backwards compatible, generally
useful, and not intrusive.

There is one problem though; it surfaced during IRC discussions with
Amos (thank you!). For example, consider authentication helpers that
need http_port name as a parameter. The feature described above will
supply those helpers with the required port information, and Squid will
cache authenticated user credentials as usual. However, it may be wrong
for a user coming in on port B to match Squid-cached credentials of a
user already authenticated on port A, even if both user names and
credentials are identical (e.g., both are called Bob and both use
"letmein" as a password). Cache invalidation is also possible if Bob on
port B is using a different password than Bob on port A, I guess.

This credentials cache collision problem does not apply to all
deployment scenarios, but sometimes those users must be segregated for
authentication to work correctly. To address this, we add an optional
request_realm parameter that tells Squid [how] to segregate users when
caching authenticated credentials:

  auth_param basic request_realm "%myportname"

The above instructs Squid to index its cache using (%myportname,
%username) pairs instead of the default %username value, essentially.

In most cases where request_realm is needed, it will simply contain the
custom request_format part(s). However, I think the two should be
configured separately because

* We need a configuration knob to disable request realms anyway.
* We will have to place unnatural restrictions on request_format syntax.
* It is quite possible that, with some helpers, certain input parts
should not affect credentials caching at all.
* The feature may be later augmented with ACLs to group large set of
values such as individual client IP addresses into compact
request_realms such as /16 networks.

[ Another alternative I considered was to add %macro support to the
existing [Squid] realm parameter and use that instead. I do not think
that is such a good idea because some authentication schemes do not have
Squid realms, and also because Squid realm strings are shown to users
and may not be appropriate for storing low-level details such as port
numbers or IP networks. ]

It is possible that, despite documentation warnings, some admins will
misconfigure this, creating huge but pointless authentication caches
and/or overloading their helpers (e.g., by specifying "%current_time" as
the request_realm). I think that risk is acceptable. We cannot offer
powerful features without also giving an admin the ability to shoot
himself in the foot.

Are there any objections to adding this feature? Any improvement ideas?

Thank you,

Alex.
P.S. It is also possible to implement a similar but different feature
where the selection of the helper is controlled by an ACL while the
helper does not receive any extra information from Squid. This will not
help admins that have to supply additional (and/or highly varied)
information to helpers, so I am not discussing that feature here. The
two features can coexist though.

(*) I am talking about "different internal authentication lookup
algorithms" for the _same_ authentication scheme (Basic, NTLM,
whatever). This feature does not change how the HTTP client and Squid
negotiate the authentication scheme to use. For simplicity, you may
assume that the scheme is always Basic authentication (or always NTLM).
Received on Fri Oct 11 2013 - 04:33:11 MDT