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

On 21.03.2012 09:40, Kinkie wrote:
>> 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.

That is essentially the long term dream I inherited from some of
Henriks and users comments.

The parser converts "allow"|"deny" into an ACCESS_* result to be output
by checklist.
With the current code we can add a simple parser update and make:

  http_access "authenticate" acl [acl ... ]

produce AUTH_REQUIRED / DUNNO instead of ALLOWED / DENIED / DUNNO

With the above, if all the ACLs on the line match auth is challenged.
Otherwise not. Following http_access lines deal with successfully
authenticates credentials. "proxy_auth REQUIRED" triggering challenge is
obsolete (external_acl_type as well?).

I was just waiting to confirm that the enums are all handled properly
throughout the ACL systems first. Then figure out how to handle
non-REQUIRED logins (*there* is a rats nest of user confusion), then add
the above in 3.3.

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

Interesting.

I've been thinking along the lines of a set of fastCheck() lines to
determine which scheme gets used:

   auth_param basic access acl [acl ...]

with support for multiple helpers of each type that is extensible to
several same-scheme helpers with different realms.

> # 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?)

see my other mail to Alex.

Amos
Received on Wed Mar 21 2012 - 00:56:01 MDT