RE: Authentication by acl

I've just finished working on an external program to use Blockade to do the
authentication. My origional plan was to have the external program read a
list of allowed groups, and then loop through the two lists to see if any
matched. If you a) don't want per-url authorization, and b) have this kind
of functionality in your external auth set, this method will work.

Incidentally, Blockade handles the group part on its own, so my code was
just a matter of calling the Blockade API for an authentication. Works
pretty slick. Once I've got it completely debugged, I'll post it.

On a side topic, has anyone looked at a combination of userid- and IP-based
authentication? For example, use the userid/password to check the first
access in a given time slot, and then fall back to IP address ACL for the
remainder of the time? Although it wouldn't do much, I was thinking that it
could help improve time, especially for users on slow/unreliable links.

Jon

> -----Original Message-----
> From: Henrik Nordstrom [SMTP:hno@hem.passagen.se]
> Sent: Sunday, November 15, 1998 10:11 AM
> To: Arjan de Vet
> Cc: squid-users@ircache.net
> Subject: Re: Authentication by acl
>
> > > Is it possible to do different user authentications based
> > > on the url a user is trying to get? Basically I would lik
> > > to be able to pass the
> >
> > After the 2.0 release many people have mailed me about these
> > kind of things. It was possible with the old scheme but with
> > the new scheme (using external authentication programs) it has
> > become more difficult or not possible at all.
>
> This specific case is possible in 2.1, using two different
> proxy_auth ACLs, as I have posted earlier.
>
> # All users are allowed to access, authenticated or not
> acl free_access dst 1.1.1.0/255.255.255.0
> http_access allow free_access
>
> # All authenticated users allowed to access
> acl all_access dst 1.1.2.0/255.255.255.0
> acl all_users proxy_auth REQUIRED
> http_access allow all_users all_access
>
> # Some authenticated users are allowed access
> acl restrict_access dst 1.1.3.0/255.255.255.0
> acl vip_users proxy_auth "/usr/local/squid/etc/vip_users"
> http_access allow vip_users restrict_access
>
> > The current specification for external authentication program
> > says that everything after the first space until the end of line
> > is the password (which can contain spaces itself).
>
> And this way should it stay. The sole purpose of the authentication
> program is to validate if the user+password pair is correct or not.
> With this "limited" functionality of the authenticator squid is
> able to cache the results, which is badly needed on most shemes
> where a external service is contacted.
>
> > I think we should start a redesign phase for the external
> > authentication method which would make it much more extensible
> > (and maybe integrating the redirector API at the same time so
> > we can have one API for both).
>
> What you essensially are looking for is a extensible access control
> method, not really authentication.
>
> My vote is that the redirector interface is rewritten to be much
> more extensible both in what Squid sends to the redirector, and
> in what a redirector may return.
>
> Another option is a "external program" ACL type, but I am not
> sure this is really needed as the redirector interface may
> be generic enought.
>
> acl program /path/to/external/program [options]
>
> where [options] is a number of options to control which
> information that is sent to the external program, and how
> many such programs that is started for this ACL.
>
> note: This is a proposal. Not something that is currently
> implemented.
>
> ---
> Henrik Nordstrom
> Spare time Squid hacker
Received on Mon Nov 16 1998 - 10:01:58 MST