Re: [SQU] Authenticate problem:

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Saturday, December 23, 2000 11:07 AM
Subject: Re: [SQU] Authenticate problem:

> Robert Collins wrote:
>
> > > Hmm.. maybe there are a proxy_auth cache defiency there. In theory the
> > > first request carrying the new passphrase would be sent to the
> > > authenticator, but maybe all are until the authenticator returns. Need
> > > to check the code on this.
> >
> > The Auth_rewrite branch should have this fixed as a 'freebie'. I'll check
> > when I get fully back on deck. If not then then it will be trivial to fix
> > in auth_rewrite.
>
> Ok. I'll await your investigation, but in the current code (not
> auth_rewrite) there surely is a window between the first query and the
> result where additional requests will spawn additional validations, and
> probably even cause duplicate entries in the cache.
>

The auth_rewrite has code that checks for the cache entries as a preference, and merges details such as moved (for single ip per
user turned on) & updated passwords into the existing cache entry. This should prevent that race. Although I need to confirm that
basic won't send a auth request out, and then find the existing user :[.. still will let you know.

> > > > > authenticate_ip_ttl
> > > >
> > > > 3600
> > >
> > > This might also be one source if the same userid tried to access Squid
> > > from two or more different IP's.
> > >
> >
> > This is fixed in auth_rewrite. We compare the passwords. in memory without an external trip.
>
> So how do you implement authenticate_ip_ttl's normal soft mode where the
> user is meant to be required to reauthenticate each time he/she switches
> IP within the TTL?
>
> In the normal code this is done by forgetting the cached credentials
> each time a switch is detected, AND to reject the request with
> "authentication required". This way the user can switch IP with only a
> minor annoyance, but if two IP's tries to use the same user then things
> will get really annoying for the user.
>
> Hmm.. could of course change it to simply change the IP instead of
> dropping the cache entry.. probably a good idea.

Yup. I think that's what I did. The basic scheme mechanism was broken for the generic case - the cached credentials were sent to the
helper again, and that wouldn't work with NTLM/Kerberos/Digest. My current case is to check the user is valid (whatever the scheme
takes to do that) and then if authenticated update the cache. The hard option denies the user once the username is known. But as
it's still beta some of these things _may_ be slightly borken. I plan to do a complete once over of the code once I've got digest
completed. Why do digest first? To make sure the API is good at the generic case - and I have found an assumption in the API I put
together already which I am going to correct.

for interest: the current auth_rewrite passes around a auth_user_t which has common user details and a pointer to scheme specific
data. This works fine for basic and NTLM, however Digest works on two levels - the HA1 which is the MD5(username+ realm +password)
and then a specific nonce for each connection. So I've implemented digest as a bit of a hack right now. I plan to go back to
auth_rewrite once all the kinks are out of digest and have it pass around a auth_user_request_t which will have generic request
related information, then two levels of structs for each auth scheme. This will simplify some of the caching logic (which is why I'm
bothering).

>
> In strict ip_ttl mode the requests from other IP's are always denied
> until the TTL have expired.

I have to confirm I haven't broken this - I don't think I have. Still as I said I'll be doing a full code review once I've finished
Digest. It is pretty much finished now but squid would be trusting user input a little to much for my comfort.

Rob
Received on Fri Dec 22 2000 - 17:20:26 MST