Re: [PATCH] Bug 3342: username token for external ACL without triggering auth validation

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sun, 18 Dec 2011 01:46:34 +1300

On 18/12/2011 12:36 a.m., Henrik Nordström wrote:
> lör 2011-12-17 klockan 17:54 +1300 skrev Amos Jeffries:
>
>> This adds a %un token (different to %LOGIN and %EXT_USER) which passes
>> any pre-known username details to the external ACL helper. But does not
>> trigger or require authentication verifications.
> A think a better approach to the last part is to add an general acl
> flag, indicating that this acl should not trigger auth (or ident?) even
> if referencing authenticated(/identified) user names.
>
> The underlying problem is in acl processing in general, not specifically
> external acls.

Aye, in that direction we have the extended ACL result enums.
I am pushing this as a partial step, both to gain that functionality and
towards the merging of the generic logformat and external ACL tokens.
Note that this is the same as logformat %un token including semantics.
%LOGIN would map better to %ua (which could gain the %LOGIN triggering
semantics without a problem).

>> This will not process auth headers if presented but not yet
>> authenticated. But it will allow IDENT and external ACL out-of-band
>> authorization usernames to be sent to the helper.
> It should probably process auth headers if presented, but not challenge
> for authentication if no headers at all are presented.

Trouble is, do we do it for all schemes? (meaning adding username
decode inline for all of them)
  or just the Basic one where username decode is already in the main code?

IMHO, doing that this early will be worse for confusion than the current
state. Not against doing it, but as a separate update later.

>
> Note: EXT_USER and USER_CERT_* both do not trigger any
> auth/identification events.
>
>> On the upside it will solve some of the cases where people want to
>> process usernames without accidental auth challenges.
> Well, that is already possible in most cases by careful usage of acls.
>
>> On the downside I am expecting some small amount of confusion as admin
>> send HTTP auth headers and expect Squid to magically understand them
>> without doing any auth processing.
> ?

NTLM and Negotiate auth have no username in current Squid until after
teh full challenge handshake is performed.

Amos
Received on Sat Dec 17 2011 - 12:48:59 MST

This archive was generated by hypermail 2.2.0 : Mon Dec 19 2011 - 12:00:09 MST