[squid-dev] [PATCH] auth_schemes directive

[Alex Rousskov]

On 12/01/2016 11:53 PM, Amos Jeffries wrote:

> Not sure if you intended to but you have just done a good CHI test.

I do not know what you mean by "CHI test". Googling did not help.


> Your wording/layout of that directive has clearly collided with some
> other config grammar that user is more familiar with from somewhere
> else.

Yes, although this has nothing to do with the example I was talking
about. And it is not "wording". Other directives assemble "lists"
implicitly, by combining the effect of multiple matching rules. In
auth_schemes case, the list is set explicitly by the first matching
rule. The list is treated as a single monolithic whole. There are other
directives where the first matching rile selects a monolithic value, but
they do not deal with lists IIRC.

The implemented design solves a couple of serious problems. The question
is whether the traditional implicit list assembly would have been better
in this case. I think (and tried to illustrate why) it would have been
worse, but others may think otherwise, of course.


> the
> intended UI for configuring it is flawed and unable to convey true
> meaning accurately.

Yes, provided NONE becomes a part of the auth_schemes UI. It is not now,
and it should not be added. Without NONE, there is no confusion. I agree
that some other, more specific magic words may be added (after careful
consideration of alternatives) to support various NONE use cases, as you
have proposed in (3) below.


> I propose:
> 
> 1) get rid of the "allow/deny" field. Make all those lines allow if all
> the line ACLs match, and skip if one of them non-match.

Done. Implemented auth_schemes do not use allow/deny. Your proposal
matches what we have implemented.

The implemented auth_schemes make it impossible to say "ALL except S1"
without explicitly enumerating all schemes:

  auth_schemes S2,S3,... acl1 ... # ugly: ALL except S1
  auth_schemes S1,S3,... acl2 ... # ugly: ALL except S2

In my earlier example of an alternative design, I considered adding
allow/deny to avoid that explicit enumeration of schemes:

  auth_schemes S1 deny acl1 ... # nice: ALL except S1
  auth_schemes S2 deny acl2 ... # nice: ALL except S2

I subsequently ruled that alternative out as inferior because it may
lead to dangerously confusing configurations like:

  auth_schemes ALL deny acl1 ... # no schemes; but what does that mean?!
  auth_schemes S1,S2,... deny acl2 ... # same problem but now _implicit_



> 2) try other names for the directive:
>    auth_scheme_order seems more clear description to me.

The _order suffix does not make sense to me because the directive
controls both order and presence; and the "presence" is a far more
common use case. I think auth_schemes is close to perfection but I am
happy to discuss other alternatives!


> 3) if necessary after (2), try other ways to name the 'none' case:
>   reject, fail-auth, no-scheme, etc.

Sounds good, but adding more magic names to supporting NONE caseS (there
are many!) can (and IMO should) be considered separately. The feature
works fine without NONE support. Deciding how to properly support NONE
cases (and which of them to support) is difficult. There is no necessity
to enlarge the scope of this project.

We seem to agree that more magic names may be added to support more use
cases, so committing the current implementation does not hurt that
future work. When the subject of other/NONE use cases is studied (as a
separate project), we should determine if those use cases are best
supported via more magic names in auth_schemes, new directives, and/or
good old http_access ACLs.


> Also, what is this "ALL" case in the above examples?
>  did you mean "default"? as in 'the default order'.

The magic ALL name stands for "all configured authentication schemes".
Here are the relevant parts of the documentation:

> +	Use this directive to customize authentication schemes presence and
> +	order in Squid's Unauthorized and Authentication Required responses.
> +
> +		auth_schemes scheme1,scheme2,... [!]aclname ...
> +
> +	where schemeN is the name of one of the authentication schemes
> +	configured using auth_param directives.

> +	A special "ALL" scheme name expands to all auth_param-configured
> +	schemes in their configuration order.

> +	The following example sends basic and negotiate authentication
> +	schemes, in that order, when requesting authentication of HTTP
> +	requests matching the isIE ACL (not shown) while sending all
> +	auth_param schemes in their configuration order to other clients:
> +
> +		auth_schemes basic,negotiate isIE
> +		auth_schemes ALL all # explicit default

Directive naming aside, since what you have proposed is already
implemented, we will proceed with splitting the patch into two parts, as
you have requested earlier. This will give you and others more time to
suggest a better name than auth_schemes.


Thank you,

Alex.