Re: External group concept

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Thursday, July 05, 2001 7:35 PM
Subject: Re: External group concept

> The way I visioned 'b' is not tied to authentication. It can be used
> without. Auth id is simply one of the group selectors.
>
> proxy_auth is on usernames, not really groups. One additional layer of
> ACL indirection is required. Maybe this can be merged into the
> proxy_auth ACL somehow,
>
> Also, groups are needed when using ident just as when using proxy auth.
>
> Hmm.. maybe what I really want is a concept of external ACL, with a
> configurable set of selectors, and the concept of proxy_auth groups
> where the group can (or must) be returned by the auth backend helper as
> part of verifying the users password.
>
> Reviced proposal:
>
> a) proxy_auth "group" concept, matching groups returned by the backend
> auth helper.
>
> Question: How to represent auth group names in proxy_auth ACL's?
>
> Note: the groups need only to be stored inside the user entry. No need
> for group structures.

I still advocate just adding the user to all the proxy_auth acls that have
names matching group names. And link to the entries in the auth_user struct
so we can clean the names trivially.

> b) "external ACL" concept, where an external helper is used to evaluate
> the ACL based on a (per ACL) configurable set of selectors
> - ident id
> - auth id
> - client IP
> - selected HTTP headers (Broswer, X-Forwarded-For, ...)
>
> result from helper lookups are cached.
>

i.e. a redirector that can be cached ? Cached against what?
ident details? (the ident username and any ident acls'?)
auth id? (the auth username, and any proxy-auth acls?)
client ip? (the client database?)

> To limit the amount of helpers needed, one indirection layer is needed
> between the ACL's and the helpers, passing one argument to the helper
> based on the actual ACL.
>
> external_acl_helper <id> <selector> </path/to/helper> <arguments>
>
> acl <name> external <id> <argument>

I'm not sure what this actually ends up caching? It seems to me that the acl
results _have_ to map against an in-squid cache that is bound to the
selector... in exactly the fashion that proxy-auth is bound to http username
and the client database to ip.

So I see no value in an "external" acl, but a lot of value in being able to
add entries to the _existing_ relevant acl's dynamically via external
helpers.

ie
acl <name> <selector> <initial entries>
external_acl_helper <selector> </path> <arguments>

acl sample srcip 192.168.0.1
external_acl_helper srcip /path <arguments>

having patterns in the arguments would be nice - ie
%u %i %url
"robert" "192.168.0.2" http://www.foo.com

Rob

> --
> Henrik
>
> Robert Collins wrote:
>
> > Yes. Both a and b need a "group" concept in squid. Adding users to
> > groups needs a global API of some sort - probably one function to add,
> > one to test for membership and one to free. After that coding a is
> > trivial for any given scheme.
> >
> > IMO the groups shouldn't be a separate ACL type though - the proxy_auth
> > acl is effectively a group acl now, just not dynamic as users login. I'd
> > like the list of proxy_auth acl's to be extended as users login, and
> > users added and removed from the acl's as they login and are cleaned
> > from the user cache respectively.
> >
> > Rob
> >
> > >
> > > --
> > > Henrik
> > >
>
Received on Thu Jul 05 2001 - 08:01:12 MDT