Re: External group concept

Robert Collins wrote:

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

Actually my mind was stuck on only considering groups, but a generic
union acl type makes sense also.

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

And only thing I disagree to is a minor technicality in '2'.

The users are NOT inserted into the proxy_auth ACL, but into the
authentication group the proxy_auth ACL definition refers to.

Because of searching requirements, the search index for a proxy_auth ACL
includes all users who either are defined in the acl definition, or
added via authentication groups referenced by the acl definition.

> 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 never liked REQUIRED. In fact, the primary reason to why it is there
is because from start proxy_auth did not have any user list at all.

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

The mapping is defined in squid.conf external_auth_helper <selector>.

The cache key is the same, plus any (optional) argument sent by the ACL.
 
> 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.

The cache is one cache per external_acl_helper definition.

Why all of the selectors is unified into one is because it allows the
external ACL to be quite complex. One example is if you have a database
of usernames and their IP addresses, and only want to allow access if
the correct user is coming from the correct IP address.

With the built-in ACL scheme, this requires one proxy_auth definition
and one srcip definition PER USER, which is all fine when you have to
specify them all in a generic config file, but not when you start
relying on external access control databases.

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

The <selector> definitions used are only imaginary. The syntax is not
yet defined. What is important here is the general concepts involved.

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

You grabbed the concept of a union and now want to extend it even
further.

As it is today, all ACL definitions are unions of all members.

http_access lines are intersections of all acl:s listed on the line.

Adding an "union" ACL type makes perfect sense, and fits very well in
the design, but it is actually outside what is being discussed here.

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

authentication groups are a group defined in your authentication
database/helper.

The purpose of acl lists in squid.conf is to assign useful names to
groups of "something" (IP addresses, users, authentication groups, ...)

The purpose of most authentication databases is not to map to sensible
Squid configurations.

> Yes. perhaps
> auth_group <proxy_auth_acl> <external group name (in some quoting
> format)>

Thich is much the same thing as

acl <name> proxy_auth <reference to external group name as a group>

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

We are pretty close, except on some minor technicalities in how
proxy_auth and authentication groups relate to each other. The end
effect is mostly the same, the configuration syntax different and the
internal design is somewhat different.

> > * How to extend the helper protocols to return group memberships?
>
> rather than
> OK
> ERR
> have
> OK <group> <group> <group> <group>...
> ERR

Fine by me.

What about Digest and NTLM schemes?

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

Here we differ.

* new proxy_auth specification syntax, allowing references to external
group names, not only users. (similar to a local group in NT access
controls, who can refer both to users and global groups)

> (can be one proxy_auth to many external (but not guaranteed to be top
> performance if that is done)).

Performance of haging one proxy_auth acl refer to N authentication
groups is identical to having it refer to 0 authentication groups but
having all active users listed. In fact, it may even be somewhat quicker
as not all users need to be indexed at all times.

> auth_group <proxy_auth_acl> <external group name (in some quoting
> format)>

Should not be needed. The groups can simply be listed in the proxy_auth
ACL refering to them...

The search index of a proxy_auth ACL are the union of all users listed
explicitly in the definition plus any users known to be members of
referenced group(s).

The (static) definition of the ACL as such is a list of user names
and/or authentication groups.

--
Henrik