Re: [squid-users] Basic auth helper over a database and cache_peer, max-try issues

On 22.05.2012 04:54, maxime.dumez wrote:
> Hello,
>
>
> I'm having issues with the authentification. A request come from an
> other proxy
> and squid manage the authentification over a databases and the
> caching.
>
> The fake basic authentification and the databases authentification
> helper work
> properly but I need to limit the retry to 3 and drop a forbidden in
> the following
> case.

Lets see if I'm understanding you correctly...

a) You want to reject the client request if they send incorrect
credentials 3 times in a row?
  ==> Squid does not support this on its proxy-auth validation at
present. A client may open unlimited parallel connections and pipeline
multiple requests on each before the first response is received back.
Also, proxies *do* multiplex/interleave requests from multiple clients
into one persistent TCP connection. Patches welcome though.
   NP: I'm thinking the best way is support for a key=value parameter
back from the helper which indicates what status code to send on the
proxy-auth response on rejects. That way the limit is completely
controlled by the helper with no guessing or mistakes by Squid.

b) You want Squid to limit its retries to 3 attempts before generating
a failure response to the client?
   http://www.squid-cache.org/Doc/config/forward_max_tries/
  It will not be a 403 forbidden message generated by Squid. It will be
400 gateway unavailable or somesuch. Since the *client* login did not
fail, the gateway (squid) has broken connectivity.
   NP: if the request gets through to the origin and gets a response
Squid does not re-try.

c) you want squid to throttle the client to 3 requests which get
401/407 responses, and convert the status on any others to 403?
   ==> this is not possible in HTTP. Each request is independent of
every other request (see [a] for why). Some auth schemes also *requires*
multiple 401/407 responses to happen before being allowed. NTLM comes to
mind easily with its 3-request handshake, but Basic auth can piggy-back
almost anything. There is simply no way to know at Squid what the client
is doing with the origin or even the local auth helper.

>
> In the current configurations (see below.) we obtain a loop of prompt
> authentification but never receive a 403 response. I have tried to
> use the
> cache_peer_access statement with the cache_peer connect-fail-limit
> without success.

connect-fail-limit is TCP/UDP/ICMP level connectivity errors. Auth
being denied is a successful HTTP transaction response, the remote end
got the request and handled it, producing a response for the client.

>
> There is a misconfiguration ?

Config looks okay. Constant loop of auth-reject is expected when
receiving constant flow of non-accepted credentials. Which appears to be
what you are describing.

> The connect-fail-limit is only on the connect state and in this case
> the ERR from
> the helper will never be count as a fail for the cache_peer ?

Yes. ERR from helper only prevents the peer being tried at all. Other
routes will be attempted instead (if any).

> Otherwise do you have any other solution ?

The solution is for the validating server to be re-written to correctly
impose this 3-strikes limitation. *It* is the node responsible for
generating 403 as one possible result of its auth testing.

For www-auth header that would be the origin server. For proxy-auth
headers that would be squid auth helper handling (missing feature, see
[a] above).

Amos
Received on Tue May 22 2012 - 00:59:26 MDT