[squid-dev] [PATCH] auth_schemes directive

[Amos Jeffries]

On 1/12/2016 8:00 a.m., Alex Rousskov wrote:
> On 11/30/2016 12:06 AM, Alex Rousskov wrote:
>> Perhaps there is a way to keep the per-scheme access list advantage
>> without opening the 403 Pandora box and preserving the whole-list
>> visualization provided by auth_schemes?
>>
>> For example, we could support something like this:
>>
>>   auth_schemes "ALL except S1"    acl1 ...
>>   auth_schemes "ALL except S1,S2" acl2 ...
>>   auth_schemes S1,S2              acl3 ...
>>   auth_schemes ALL                acl4 ...
>>
>> but I do not like how this syntax essentially moves operators inside
>> quoted strings.
>>
>> Another alternative is:
>>
>>   auth_schemes S1    deny  acl1 ... # ALL except S1
>>   auth_schemes S1,S2 deny  acl2 ... # ALL except S1 and S2
>>   auth_schemes S1,S2 allow acl3 ... # just S1 and S2
>>   auth_schemes ALL   allow acl4 ... # ALL
>>
>> (with the configuration implementation similar to the existing
>> request_header_access rules).
>>
>> Unfortunately, in all these cases, we would have to special-case
>> denying/excepting all schemes to avoid opening the 403 Pandora box. Only
>> the current auth_schemes implementation avoids that 403 problem (because
>> an empty list is a syntax-level/configure-time violation).
> 
> I just got a nice illustration why that 403-via-lack-of-schemes Pandora
> box should remain closed:
> 
> A customer has indicated that "auth_schemes NONE" support would make
> writing their configurations a little easier. That comment appeared to
> support your assertion that lack-of-schemes should be treated as a
> special useful 403 Forbidden case. However, to my surprise, the
> follow-up conversation revealed that the customer expected "auth_schemes
> NONE" to _allow_ access, not forbid it!

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

One of the top UI design rules is that users feel comfortable with UI
things they have repeated.
 A user enjoying new experience with something means previous experience
with another UI of the same structure.
 Most of the time familiarity is a good thing. But one has to be very
careful to actually follow the common design pattern, and not lead to
implicit contradictions.

Your wording/layout of that directive has clearly collided with some
other config grammar that user is more familiar with from somewhere
else. It may even be a collision with the other Squid directive
patterns. see (1) below.


> 
> This example of diametrically opposed expectations reinforces my
> original worries about supporting this special "no authentication
> schemes" case. I think we should continue to rely on http_access to
> permit or forbid access (including permitting or forbidding access
> without authentication) and require at least one authentication scheme
> to be available when authentication schemes are configured/used.

The CHI test says nothing about the case itself. It says that the
intended UI for configuring it is flawed and unable to convey true
meaning accurately.

If the user had understood it correctly and still had trouble with it
there would be a worry about supporting it.


> 
> Said that, there might still be a way to configure the list of schemes
> better than the posted auth_schemes does. I have not found it yet though.
> 

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.

We have a common pattern in Squid that directives allowing/denying
access to traffic pathways use allow/deny keywords, but directives that
control some component of Squid being enabled/disabled just have a list
of ACL names and the directive "thing" happens if they all match.

This directive is one of the latter type. So it would be more consistent
with existing pattern if they were not there. It does make config
slightly less convenient, but that can be balanced partially by using
all-of ACL.


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


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


Though IMO you should find that just (1) and (2) are sufficient:

 The line "auth_scheme_order none all" etc. seems more likely to lead a
user to "WTF, I have to look that up" than assuming wrong knowledge
about access being allowed.


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

Amos