Re: PATCH: Proxy Authentication patches

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).

> 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.

> 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.

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)

/Henrik
Received on Tue Jul 29 2003 - 13:15:58 MDT