RE: external ACL

From: Chemolli Francesco (USI) <ChemolliF@dont-contact.us>
Date: Thu, 19 Jul 2001 11:04:05 +0200

> > Robert Collins wrote:
> > >
> > > So you want to force authentication if not present?
> > >
> > > Three possible ways
> > > 1) duplicate code from the proxy_auth ACL type. Remembering that
> > > _authentication_ vs authorisation is all modularised in
> authenticate.c
> > > 2) have the user add
> > > acl foo proxy_auth REQUIRED
> > > and then write their external acl access rules that use
> %LOGIN as (say)
> > > http_access deny !foo external external !external
> > > 3) dynamically insert the data for 2) when parsing, if
> you encounter
> %LOGIN
> > > in a external_acl rule.
> > >
> > > I favour 3 - it's a bit harder to do _right_, but the
> user may be less
> > > confused.
> > >
> > > Rob
> >
> > Or 4, make challenge processing/generation/IP verification
> more cleanly
> > separated from the proxy_auth ACL match.
>
> I've no objection to tweaking/refactoring/whateveryouwanttocallit the
> abstraction. It's not quite right as it is. I have some
> pending work in ntlm
> that will affect such rearrangements - I'll try and get it
> finished up asap,
> and see if I can rearrange the logic at the same time.
>
> I don't think the IP verifcation should be tied to the
> authentication too
> tightly - the whole point of external acl's as I understood
> was to allow
> more custom processing. Thoughts here?

IMO IP verification is more of an authorization than authentication issue.
The "problem" here is that we want to be lazy in performing authentication,
and do that only when it is needed for authentication.

NetCache AFAICS does things differently: its ACLs are in the form:

deny url "blah"
allow src-ip "blah"
auth http
allow user "blah"

AFAIK no user-related caluses are allowed before the auth http
call.
This places upon the user the burden of deciding WHEN to perform the
authentication. It's less flexible than squid's way to do things, but
I think it's simpler to implement. The "allow user" lines do NOT imply
an authentication challenge, and the authentication challenge is decoupled
from the authorization phase. It simpler because authorization is then fully
synchronous and thus there is less state to track, while authentication has
a fully distributed state with very little state information associated with
it.

-- 
	/kinkie 
Received on Thu Jul 19 2001 - 02:57:00 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:07 MST