RE: External group concept

We've ended up with ~3 parallel emails so I'm going to respond to all of
them here... I may end up repeating myself :}
 

> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
> Sent: Friday, July 06, 2001 12:08 AM
> To: Robert Collins
> Cc: squid-dev@squid-cache.org
> Subject: Re: External group concept
>
>
> Robert Collins wrote:
>
> > I was suggesting that squid dynamically add users to proxy
> > auth acls when informed by the helper that was necessary.
>
> Naa... but proxy_auth ACL's could be made to refer to auth groups, not
> only user names. Mostly needs a syntax definition, and support in the
> helper protocol.
>
> Want to be able to make lists of groups (unions, not intersections as
> done by http_access).

Ah, an acl that creates the union of other acls. Nice idea - and I think
squid needs it as a general thing.

i.e.
acl <name> union <aclname1> <aclname2> <aclname3>
and when <name> is tested in a foo_access statement, it matches if any
of the listed acls' match. I think this can be done orthogonally to
group functionality though.
 
> > We can do more than 1. We can have a separate helper and/or
> tie it into the
> > authentication helper. I think thats what Henrik meant with
> his a)/b)
> > options.
>
> Yes, and both are required I think.
>
> 'a' is tied to the authentication helper.
>
> 'b' is a separate helper, not really groups but can be used
> to implement
> groups. Not at all tied to authentication (except that
> authentication ID
> can be one of the selection criterias)

Yes.

> > I agree - I'm saying that "proxy_auth" IS group acls. We
> don't have a
> > user-name checking facility today. (We can't say
> > http_access allow userrobert
> > unless we define a group userrobert with the user "robert" in it.
>
> Correct.
>
> Hoever, proxy_auth IS the group definition, not the ACL telling which
> groups to match.
>
> Lets say your authentication system has 20 different groups, all
> published by the auth helper to Squid.
>
> You want to give 5 of these groups access to a given resource, deny 6
> from some other resource, and allow 2 to proxy to anything else.

Yep. I agree. I don't think that needs to be limited to a single sub acl
type though.
so at this point we've got three things:
1. acl <name> union <...>
2. auth helpers that can grab directory group membership data - by which
I mean what proxy_auth acl(s) to insert the username into.
3. Your external checking helper.

>
> --
> Henrik
>
> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
> Sent: Friday, July 06, 2001 1:59 AM
> To: Robert Collins
> Cc: squid-dev@squid-cache.org
> Subject: 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.

Like dns cache entries? Or usernames (acl foo proxy_auth REQUIRED). We
do this today. Doing it on a slightly larger scale shouldn't be any
messier :} - or perhaps what we do today needs revisiting.
 
> > 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.

What I'm confused about is how you are defining the mapping - or are you
passing the entire request details every time. (i.e. the squid srcip acl
code "knows" that the url and proxy auth username are irrelevant - how
does the in-squid cache code for the external helper create the cache
keys?). If it's _just_ the selector, I think we end up having
count(<selectortype>) different helper API's and helpers.
 
> > 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.

Hmm. I think I'm kinda lost :]. Mental block of some sort.
 
> > 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.

Ok. This is what I was saying before - the generic squid.conf syntax
actually maps to srcip in this case. And if only the srcip address is
given, the external helper can't perform arbitrary tests - which is one
of the benefits you're proposing. (I'm not against what you're
suggesting - just trying to understand it).
 
>
> 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.

So the LOGIN selector means the auth user. And then you have a set of
count(<selectorid>) caches to drive this. I don't know that it's a good
idea to have all the different selectors driven through the same code -
too me it would make more sense to have generic acl result caching, and
then a set of acl's that have their own config lines. Alteratively,
ensuring that their is a registration API within squid to add selectors
and the selector specific code. The goal being to stay modular, without
sacrificing speed.

BTW: I can see that the results here should not modify configuration
data, but only alter the runtime cache. Thats finally clicked :].
 
> 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.

Hmm. How does squid know that IDENT isn't the path and /path/to/helper
the arguments? That needs quoting in some fashion. (ie
path=/path/to/helper indicates end of selectors).

This is going to be somewhat tricky - the cache key format will have to
be defined at runtime. Still I can see the advantages - I'm very keen to
keep whatever we create for this modular though.
 
> --
> Henrik
>
> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
> Sent: Friday, July 06, 2001 3:46 AM
> To: Robert Collins
> Cc: Chemolli Francesco (USI); squid-dev@squid-cache.org
> Subject: Re: External group concept
>
>
> Robert Collins wrote:
>
> > > For auth groups, no separate group definitions are
> required. Simply
> > > cache the group memberships returned by the helper in the
> users auth
> > > cache entry, and for speed of lookup maintain a group->user index.
> >
> > ... If no definition is required, how do the groups get
> tested against in
> > http_access rules? This is where I'm suggesting we use the
> proxy_auth acl
> > names.
>
> I have been a bit unclear there I admit. Easily gets that way when one
> prematurely jumps into details
>
> As you correctly say group definitions are needed one way or another.
> Where we differ is how these definitions are to be maintained.
>
> Your proposal is to make the auth code automatically modify proxy_auth
> ACL's to show group membership.
>
> I at intuitively dislike this, but it may have some merit. If we do a
> union of both yours and mine proxy_auth related proposal I think there
> is a acceptable design.

Yes.
 
> Your other proposal is to have auth group names the same as acl names.
> This I see as unacceptable because
>
> a) It may be convenient to make unions of several auth groups into one
> Squid ACL to easily refer to both groups of users in a single
> http_access line.

I like you union concept - It's currently missing and would be very
useful. I think that limiting it to proxy_auth acl's would be wasteful.
My suggestion for naming the groups the same as the proxy_auth acls was
for the case where the groups _are_ the lists of users, not lists of
groups.
 
> b) Group names are often selected in a context quite far from Squid
> configuration, making them somewhat unsuitable for good looking Squid
> configs.
>
> proxy_auth configuration syntax is extended with references to auth
> groups.

Yes. perhaps
auth_group <proxy_auth_acl> <external group name (in some quoting
format)>
 
> authenticated users are added to any proxy_auth ACL who referes to any
> of the users group memberships, with a flag indicating that this user
> entry is "group internal".
>
> When a user auth cache entry is expired or new group membership
> information has been received from helper revalidation, the user is
> first removed from any proxy_auth ACL's refering to it's (old) group
> memberships.
>
> This way we have a nice and clean lookup path, combined with a
> reasonable configuration syntax.
>
> The only indexes needed to be added is "group name" -> "proxy_auth ACL
> names".
>
> Now the final questions:
>
> * How to syntactically refer to group names in proxy_auth?

I still maintain that for *this purpose* proxy_auth acls on their own
are fine. Adding a new union style acl that can be used to collate
different proxy_auth groups should add the appropriate functionality,
and be fast and effective.
 
> * How to extend the helper protocols to return group memberships?

rather than
OK
ERR
have
OK <group> <group> <group> <group>...
ERR

:].
 
> Note: I see this restricted to groups which can only be
> returned as part
> of the authentication process. For groups which are not tied
> to "logging
> in" see "external ACL".

Yes. So in summary (repeating myself I know)

1) get group names from the actual authenticators
*) extend each helper protocol slightly. (NTLM, basic, digest)
*) new config directive to map proxy_auth acls to external group names.
(can be one proxy_auth to many external (but not guaranteed to be top
performance if that is done)).
auth_group <proxy_auth_acl> <external group name (in some quoting
format)>
ie
auth_group users DOMAIN2\00334
auth_group staff DOMAIN2\00332
** next 2 allowed but not best way:
auth_group staff DOMAIN1\01234
auth-group staff cn=.... (some ldap group definition)
** next 2 not allowed - or should it be? It will add to the cache mgmt
overhead, and I don't think it's useful because staff then == users.
auth_group staff DOMAIN1\12345
auth_group users DOMAIN1\12345
*) Some global authenticate.c code to add a user to each mapped
proxy_auth_acl when adding the user to the cache. When they are cleaned
the dynamically added entries are removed.

2) union acl to group different acl's together prior to foo_access
lines.
*) new acl
acl <name> union <otheracl> <otheracl> <otheracl>
ie
acl staff union domain1staff domain2staff
acl visitors union srcipacl proxyauthacl
*) in reference to 1) above, can tie several several proxy auth acl's
together.

3) external helper driven acl's
*) as you've described :].

Rob

 
> --
> Henrik
>
Received on Thu Jul 05 2001 - 23:54:03 MDT