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.

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.

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>

--
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
> >