On 07.03.2012 15:44, Amos Jeffries wrote:
> On 07.03.2012 14:23, Brett Lymn wrote:
>> Following up on myself...
>>
>> On Fri, Mar 02, 2012 at 01:59:27PM +1030, Brett Lymn wrote:
>>>
>>> At the moment I am looking at setting up a LDAP proxy for the
>>> upstream
>>> to query and then use login=*:password in squid. This should allow
>>> me
>>> to make the upstream proxy believe it is authenticating so that it
>>> has
>>> the username it wants.
>>>
>>
>> OK, I have good news/bad news about this approach. The good news is
>> with
>> the help of:
>>
> [ snip the bad news :( ]
>
>>
>> So, it seems that I need to strip the username back to just a bare
>> name.
>> From what Amos said earlier it seems I can do this with an
>> external
>> acl, if I use this acl will the username be available for login=*?
>> or do
>> I need to use login=PASS? If I use login=PASS will I still get
>> authentication on squid as well? (I really need squid to auth the
>> client) or is there another way I can mangle the username to my
>> needs?
>
> cache_peer option of "login=PASS", with the external_acl_type helper
> returning values in both user= and password= parameters.
>
Oops. Forgot to answer your other questions.
The above will not affect any authentication between the client and
Squid. The two proxy-auth logins are separate.
To be on the paranoid / safe side you can use another little trick:
testing the helper in a "never_direct deny ..." or "always_direct allow
..." line.
The allow/deny for those cases is meaningless, those *_access are only
run when sending a request upstream, and are able to run slow helper
lookups, and they are well out of the way of client authentication in
http_access.
Amos
Received on Wed Mar 07 2012 - 02:56:21 MST
This archive was generated by hypermail 2.2.0 : Wed Mar 07 2012 - 12:00:02 MST