Re: auth_rewrite authenticate.c user_auth_hash_pointer usage

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Sunday, January 14, 2001 12:24 PM
Subject: Re: auth_rewrite authenticate.c user_auth_hash_pointer usage

> Robert Collins wrote:
>
> > I dislike that too.. but it makes the framework more complex for
> > little gain. A given user is only likely to be in the cache with
> > different schemes if they are using different software in a short
> > timespan (and ntlm is unlikely to cross over with basic or
> > digest - so it will be very rare to have that occur). I don't think
> > it's going to be that common.
>
> Well, imagine that one wants to replace the username hash by a splay
> tree or some other more dynamic structure..

Yes. There should be a authenticate framework level function that finds the user. This depends on the module ID becoming pervasive -
which is one of the things I still want to do. Remember the auth_rewrite that went in was stable code, where I could draw a line in
the sand, and say - this works. It shoudn't crash, chew up all your memory or overwrite data :-]

So I agree with you..

>
> The current design depends on the layout of the hash implementation,
> digging into hash internal fields (the next pointer) to be able to
> locate search for the scheme specific auth_user. Most people assume that
> when you have a hash there is one single entry per key.

The design doesn't: the absence of a generic find function that takes username and scheme id and returns a pointer is the issue.

> Third, it is not too unexpected to see basic and ntlm share the same
> userdatabase. In such cases it would be good if the auth_user was shared
> so IP-checks and such things also was shared (else a IE user could share
> his account with a friend using Netscape, without triggering the IP
> check).

Yes, but DOMAIN\john != john. And in a NTLM environment it is realistic to expect us to have DOMAIN1\john, DOMAIN2\john. So this
could be a optional feature.

The IP check is covered under the other topic we discussed: creating a list of IP's rather than just one, and then locking in a
single ip becomes checking for list.head==NULL, allowing multiple ip's is trivial, and they can be tracked. NOTE: RFC 2617 suggests
that IP lockdowns are not good - and digest doesn't tie nonces or users to IP, just to nonce to username.

> > To do that I think several things should happen first: some of
> > the auth_user items are used in each scheme. The layout of data
> > needs to be tuned so no auth_user_t data is altered by schemes.
>
> The auth_user should only contain information specific to that user,
> irregardless of scheme.
> * user name
> * IP
> * last reference
> * what else that is independent of sheme

username is independent, but when it is found is very scheme dependent. That's why I split it off - because basic finds it
immediately, digest after 1 challenge, and NTLM after the two challenges..

> none of these should be altered by schemes.

Well the scheme has to provide the username. Some schemes may require a lockdown on the ip as part of the protocol, some may not.
Last reference shouldn't be altered by schemes, but how do you know when a suer has actually been referenced? By when the scheme
decodes &| authenticates the user. So we will end up with trivial callbacks to authenticate.c (which I don't object to - but these
bits and pieces have become more clear after the fact of splitting it up into modules.)

Also with last reference, we need last reference per scheme. ie basic credentials can timeout, NTLM can hit max reuses, digest
nonces can hit max uses (which we have currently). But currently when (digest say) times out, the entire memory gets freed up.

>
> > The AUTH_DIGEST/AUTH_BASIC/AUTH_NTLM defines need to be optimised
> > out for the module Id or a pointer to the scheme_list entry.
>
> Using a pointer is trivial, and you already have a scheme registry,
> doesn't you?

Yes - the genesis of the code went, #Define AUTH_BASIC... then modular functions, then actual scheme modules (based on the fs
modular support code)
So it's there and getting it fully supported is not to big a job.

> > Then
> > a couple of support functions at the framework level to allow
> > schemes to say "I have user joe" and get linked in. Then some very
> > very very careful testing to make sure we never cross over from
> > one scheme to another while handling a request.
>
> The cross-over issue you already have to worry about, only at a slightly
> different place (auth_user, instead of auth_user->scheme).

Uhh not the same issue:
currently acl.c requests a auth_user_request structure, and then passes that around the rest of squid. That points to a auth_user
structure (1 per username per scheme). So we can't hop schemes.

When we have auth_user_request pointing to a auth_user structure with a list of scheme_data we will have to check every single time
that we are on the correct scheme for that auth_user_request.

Like I said, can be done, should be done, but adds complexity that is not immediately beneficial.

I still think the first thing to do is make the scheme id /a scheme pointer pervasive, and tidy up the minor boundary violations (ie
basic altering timestamps) and then see where it's ready to go.

Rob
Received on Sat Jan 13 2001 - 18:48:39 MST