Re: External group concept

Robert Collins wrote:

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

Gets rather messy I'd say.. mixing configuration and dynamic data.

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

What I am talking about is as much a redirector as a basic auth helper
is.

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

Yes, exactly. What is cached is helper lookups. Questions sent to the
helper and answers received on these questions.

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

I very much dislike having configured ACL's change dynamically in that
way.

What i am proposing is a single mechanism for a helper driven ACL, with
cachable results. Very much like the auth helpers in principle, but with
a much larger selector than only username, and not including password.

Also, as it combines several selectors it can be do far more detailed
access control than what is practival with the current ACL constructs.

> 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

And with what I propose it would become

acl sample external srcip
external_acl_helper srcip SOURCE_IP /path/to/helper

where SOURCE_IP is a selector specifier telling that the helper want's
the users IP address.

The helper would be sent the users source IP, and respond with OK/ERR
(or some other positive/negative response). A cache is built on this to
not have to requery the helper on each and every request.

Given a more interesting example where you want to match against for
example LDAP groups

acl sample2_1 external ldapgroup cn=group1,ou=groups
acl sample2_2 external ldapgroup cn=group2,ou=groups
acl sample2_3 external ldapgroup cn=group3,ou=groups

external_acl_helper ldapgroup LOGIN /path/to/ldap_group_helper -b
dc=example,dc=com

The helper is sent the authenticated user id, and the cn=group1... acl
argument.

Another interesting example, where the control is based on a combination
of two attributes

acl sample3 external userip
external_acl_helper userip SOURCE_IP LOGIN /path/to/helper

Or a similar one, using ident instead of proxy authentication

acl sample4 exernal identip
external_acl_helper identip SOURCE_IP IDENT /path/to/helper

to verify that the user is coming from the IP he/she is registered for.

--
Henrik