[squid-users] Re: Authentication caching

"Henrik Nordström" <henrik_at_henriknordstrom.net> wrote in message
news:1270330950.9955.60.camel_at_localhost.localdomain...
> lör 2010-03-27 klockan 18:42 +0100 skrev Khaled Blah:
>> Hi all,
>>
>> I'm developing an authentication helper (Negotiate/NTLM) for squid and
>> I am trying to understand more how squid handles this process
>> internally. Most of all I'd like to know how and how long squid caches
>> authentication results. I have looked at the debug logs and they show
>> that squid seems to do "less caching" for Negotiate/NTLM than it does
>> for Basic/Digest authentication.
>
> Due to the nature of NTLM & Negotate authentication it's the helper
> performing the Negotiate/NTLM handshake, and because of this there is no
> cache in Squid for these schemes as there is nothing to use as cache
> key.
>
> basic & digest auth is handled internally by Squid, and enables Squid to
> cache the credentials validity.
>
> In theory we could implement NTLM in similar manner, but it would then
> not be possible to integrate with Windows domain controllers / active
> directory.
>
> Don't know enough of Kerberos to tell what possibilities there may be to
> cache in Negotiate auth.
>

In the case of Kerberos each request which has the Negotiate header has data
encrypted with the key which is stored in the keytab. The server will just
decrypt the data with the key from the keytab and if successful return the
username contained in the decrypted data. There is no possibility to cache
anything.

>> I am wondering whether I can do
>> something about this so that a once verified user will only get his
>> credentials re-verified after a certain time and not all during. I am
>> grateful to any insight the list can give me. Thanks in advance!
>
> In 2.7 there is a generic auth cache based on source IP, useful when the
> clients are single-user workstations.
>
> Regards
> Henrik
>
>
Received on Mon Apr 05 2010 - 11:03:22 MDT