Re: [squid-users] request_header_add question

On 11/04/2014 10:18 p.m., Kein Name wrote:
>
>
> Amos Jeffries schrieb:
>>> Config:
>>> cache_peer 10.1.2.3 parent 8000 0 no-query originserver login=PASS
>>>
>>
>> This is a origin server peer. The header delivered to it is
>> WWW-Authenticate. Proxy-Authenticate is invalid on connections to origin
>> servers.
>>
>> Is your proxy a reverse-proxy or a forward-proxy?
>>
>
>
> It is a reverse proxy.
>

Okay. In which case Squid is operating as an origin itself. As in;
working solely on the WWW-Authenticate header and you can switch all my
earlier mentions of Proxy-Auth header to WWW-Auth.

>
>> Which of the servers (your proxy or the origin) is validating the
>> authentication?
>>
>>
>
> The origin server.
>

That might explain why %ul is not working. %ul is the username from
login authenticated / validated by the proxy.

If the proxy is not validating the authentication itself, then you only
have access to the username via an external ACL helper partially
decoding the auth header token and returning the username found to Squid.
 That value appears in either %un "any user name/label known" or %ue
"user=X kv-pair from external ACL helper"

>
>>> The config seems to work, squid shows me the login dialog of the
>>> cache_peer. For several reasons I have to feed the username back as a
>>> header value....
>>> I also tried login=PASSTHRU for testing, but without any difference.
>>
>> FWIW:
>> * "PASSTHRU" sends the received Proxy-Authenticate header (if any)
>> through to the peer untouched. Leaving no header if none provided by the
>> client.

For NTLM on a reverse-proxy with the origin performing authenticate is
exactly why this PASSTHRU was created.

You *may* also need the connection-auth=on option to be set on both the
http_port directive and the cache_peer directive since authentication is
not enabled in the proxy. End-to-end connection pinning required by NTLM
should be enabled automatically when the WWW-Authenticate:NTLM is
sighted, but these ensure that it is working anyway.

>>
>> * "PASS" tries to convert credentials to Basic auth and deliver to the
>> peer in Proxy-Authenticate. Will try to generate a header from any
>> available other sources of credentials if none are provided by the client.
>>
>> In both of the above the peer being an origin treats them as not having
>> www-Authenticate header (naturally) and responds with a challenge to get
>> some.
>>
>>
>
> The origin peer creates the "WWW-Authenticate: NTLM" request upon which
> the rev proxy shows the user/password popup request.
> The Rev Proxy then replies with a "Authorization: NTLM
> TlRMTVNTUAADAAAAGAAYAGYAAADuAO4A [...]" Header.
> So I think PASS is OK, as nothing seems to be converted from NTLM...
> Or am I wrong?

By "proxy" I hope you mean these details are coming from the client and
being passed on as-is by the proxy?

Amos
Received on Fri Apr 11 2014 - 13:39:47 MDT