Re: PATCH: Proxy Authentication patches

Henrik Nordstrom wrote:
>
> Dancer wrote:
>
> > We have 1400 schools attached to each deployment, and each school has
> > it's own username namespace. So, AUTH_WITH_IP was an obvious starting
> > point, as we needed to disable the internal auth-caching, and make sure
> > the authenticator sees the source address, so we can work out which
> > school the username is for.
>
> You could change the auth-cache to include the source IP in the cache
> key. Passing every request to the authenticator will be a performance
> dog (high latency, some CPU, requires many redirector processes).

Indeed. The authenticator currently implements a small cache
(300seconds, and 32 slots), but I'm thinking of hacking squid's own
auth-cache before deployment. If I do, I'll issue a new patch.
>
> > So, I added USERDATA_FROM_AUTHENTICATOR so that when I was given the
> > source-ip, username and password, I could return a new username string
> > with schoolname/username that would go into the logs, get passed to the
> > redirector and so on, eliminating all that repeat effort.
>
> I think we need to look at both authenticator and redirector messages,
> and see if we can find a suitable model which allows for extensions.
> Preferably while preserving backward compability.

Well, it's _currently_ backward compatible, in that, if your
authenticator returns extra data to an unmodified squid, squid ignores
it (it gets chopped off in the reply handler, which specifically looks
for whitespace)
>
> > Magic key: Hmm. Not a bad thought. I _do_ feel a little jealous about
> > every extra byte written or parsed (since we've traditionally had some
> > performance problems with the proxy boxen), but I can see your point.
> > Are you suggesting the 'USER:' in place of the 'OK', or appended?
>
> Appended after the status.

I'll see how I'm fixed for time. The boss tells me he wants me to spend
some more time doing public squid-dev stuff again (after having realised
that I haven't for a while). Nobody's quite clear on where I'm supposed
to get the time _from_, but I believe a portion of my workday is to be
given over to OSS squid hacking for The Public Good(tm). Damned if I
know quite when I can do this. As and when, I suppose.

> After giving it some additional thought I propose the following syntax:
> authenticator-query = username SP password *( SP auth-parameter)
> username = <URL encoded username>
> password = <URL encoded password>
> auth-parameter = auth-param-name ":" value
> auth-param-name = "SRCIP" | "SRCHOST" | "IDENT" | ...
> value = <URL encoded string, must not include
> unencoded whitespace>
>
> authenticator-reply = auth-status *( SP authrep-extinfo )
> auth-status = "OK" | "ERR" | "DENY"
> authrep-extinfo = auth-repinfo-name ":" value
> auth-repinfo-name = "LOGUSER" | "MESSAGE" | "REDIRECT"
>
> Hmm.. actually when thinking even further, only the responses should be
> tagged. The format of queries should be controlled from squid.conf, or
> by a initial handshake at startup. This is to greatly simplify the
> parser in the authenticator module.
>
> squid.conf approach:
> authenticator_format userid|passsword|srcip|ident|... ...
> where the default authenticator format translates to:
> authenticator_format userid password
> and your patched format to
> authenticator_format srcip userid password
>
> Handshake approach:
> Upon startup Squid sends a magic string to the authenticator/redirector.
> If recognised then the reply includes a format description, else use
> standard format.
>
> (or perhaps a combined approach)

Both ideas have a fair bit of merit. I think the handshake idea is
potentially a little more idiotproof, since regardless of what sort of
helper-app the proxy-operator plugs in, if it conforms to the handshake,
squid will know what to give it, whereas the user may have all sorts of
weird notions about it, or make typos, or false assumptions.

Actually, this brings up a related issue. My redirectors take rather a
long time to load up and get ready...despite the preprocessing of rules,
the time from dot to ready-to-serve is around forty seconds. (I'm
looking into Asynchronous loading, but it's policy that we don't serve
requests until a full setof filters is loaded).

 If there _was_ a handshake phase, it could also serve double-duty in
signalling that the helper-apps are ready, and would give warning in the
case that authenticators or redirectors are in an unrunnable state
(rather than waiting to try to use one before you find out that it
terminated immediately after startup).

D
(Did that make any sense, or should I get more coffee?)
Received on Tue Jul 29 2003 - 13:15:58 MDT