Re: [RFC] Handle ACLs that are neither denied nor allowed

> Http_access belongs to #1. ssl_bump belongs to #2. The high-level Squid
> code that initiates ACL checking should know its category and use the
> right API. The low-level ACL code cannot make this determination -- it
> should just rely on the high-level code setting the appropriate options
> to allow or prohibit outcomes that trigger authentication.

Hm.. there may be another option. Why don't we explicitly ask the
administrator to define at what point of the authorization process
authentication should be requested by the user?

We could define a third type of http_access clause, besides allow and
deny. Let's name it "authenticate" (with an optional "force" flag, we
see later)..
Upon reaching it:
- if an authentication header was provider, process it. This may
require emitting further http/407's.
 - if authentication succeeds, decorate the request with the user's
identity, pin it if needed etc. Fall through for the "real"
authorization.
 - if authentication fails and no "force" flag given, fall through.
Identity is not available to following clauses
 - if authentication fails and force flag given, challenge again (http/407)
- if none was provided,
 - challenge (http/407).

Advantages over the current approach:
- more predictable for admins
- more flexible
- could pave the road for multiple authentication backends over the
same protocol.

e.g (pseudo-config)
auth_param basic program ldap_auth serverA credentials filter ... realm RealmA
auth_param basic program ldap_auth serverB credentials filter ... realm RealmB

acl networkWithClassAUsers src 192.168.0.0/24
acl networkWithClassBUsers src 192.168.128.0/24

acl UsersA proxy_auth userA1 userA2
acl UsersB proxy_auth userB1 userB2

http_access allow manager localhost
http_access deny manager

#this will never match: we don't know the user yet.
http_access deny UsersA

# authenticate against RealmA program in A network
http_access authenticate RealmA networkWithClassAUsers
# authenticate against RealmB program in B network
http_access authenticate RealmB networkWithClassBUsers

# IF UsersB, http/403.
http_access deny UsersB

http_access allow something somewhere somehow
http_access deny all

This assumes that authentication happens early in the process flow, so
that identity may be made available to other engines which require it
later on (e.g. ssl_bump).

What do you think?

Granted, it doesn't take into account the case of credentials becoming
stale (under what conditions that may happen?)

-- 
    /kinkie