Re: authenticate_ttl

On 29 Aug 2001 15:44:19 +0200, Henrik Nordstrom wrote:
> Robert Collins wrote:
>
> > the scheme specific credentialsttl determines how long the credentials
> > for a username from a specific scheme can be cached without revisiting
> > the helper.
> >
> > The global authenticate_ttl determines how long a usernames details in
> > the global proxyuser cache are kept in memory without any activity
> > occuring.
>
> squid.conf says:
>
> authenticate_ttl
>
> The time a user & their credentials stay in the logged in user
> cache
> since their last request. When the garbage interval passes, all
> user credentials that have passed their TTL are removed from
> memory.
>
>
> I think that part of my confusion is from the fact that we now have
> multiple schemes, and that the description of authenticate_ttl speaks about
> user credentials.

Right. I'll think up a better wording to avoid that.

> Can you please explain the relations between the global cache and scheme
> credential caches and their uses. What is stored where, and how is it used,
> plus the respective cache keys/lookup strategies.

Some/most of this is in the programmers guide. It's a little bitrotten
though - on my todo list.

The global cache stores pointers to auth_user_t structs.
Each of those has
type - basic/ntlm/digest
a pointer to the hash key - which is not necessarily the username. It
might be the base64 proxy auth header for instance.
a dlink list of auth authenticate strings that refer to this user
a dlink list for the proxy_match_cache (*1)
a dlink list of the ips this user has been seen at, and a cached count
for that list.
a flags structure
  one entry credentials_ok which needs to be removed - on my todo list
expiry time for the global cache
reference count for the struct
scheme specific data pointer
dlink list of auth_user_request structures that link to the auth_user_t
struct. (this struct is self documented).

This cache is used to allow the user meta data to persist in squid
independently of a particular password/digest nonce/ntlm connection. The
authentication framework manages the cache, and provides API calls to
add and remove given auth_user_t structs from it.
It's up to the scheme code to decide that a auth_user_t is ready to be
added, or needs to be removed.
If squid sees no requests for a given auth_user_t for authenticate_ttl
seconds, then the cache entry is removed.
- cache keys are scheme dependant.
- currently uses the hash module, could be anything.

scheme credential cache?
basic - There is none. The scheme credentials are found via the global
cache.
digest - there is a temporary list of handed out nonces, but once a
nonce is associated with a username, it operates like basic.
ntlm - there is none, the handed out challenge is found by the next
request via a link in the connection data.

the credentials ttl you are referring to is a basic scheme only
parameter, used to determine when the user:password combination is no
longer valid. I.e. if the last time the user:password was checked was 50
minutes ago, send this user:password to the helper - even if it is the
same as the current one.

NTLM's equivalent is the challenge refresh stuff -
max_challenge_reuses
max_challenge_lifetime

because the actual user credentials are in theory one-shot anyway. Once
the challenge from a given helper is not allowed to be reused again, the
credentials (challenge:response pairs) obtained are invalidated.

Digest has no equivalent at the moment. It probably needs one though -
H(A1) will change when a user changes their password. So digest needs a
ha1_ttl entry.

Is that more or less clear?

Rob

*1 - acl caching logic to optimise multiple proxy_auth lookups. Can be
made generic - I have nearly done so in generic modules branch which
would drop cpu use for multiple regexs significantly. (ie when a given
acl foo is used on multiple http_access lines for a single request, we
evaluate foo multiple times. This is not smart).

>
> --
> Henrik
>
Received on Wed Aug 29 2001 - 08:30:57 MDT