[squid-users] LDAP Auth re-prompting for credentials on browser close, need suggestions

[Amos Jeffries]

On 31/07/2015 3:36 a.m., Michael Monette wrote:
> 
> 
> On 7/29/2015 5:20 PM, Amos Jeffries wrote:
>>
>>> Found this post asking the same question:
>>> http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Ldap-Authen-AD-how-to-make-authentication-persistent-td3604487.html
>>>
>>> and it
>>>
>>> There were two suggestions that stood out:
>>>
>>> There used to be a "authenticate_ip_shortcircuit_ttl" option in squid
>>> 2.7 that when authenticated successfully, it would remember the users
>>> IP for X amount of time and would let you avoid logging in every time
>>> you reopen your browser. They removed that in later versions
>>> unfortunately, I guess because someone could take over your IP and
>>> would be able to authenticate as you(which is not a concern to me, at
>>> all).
>> It should.
>>
>> Theres this thing called NAT you see, which places multiple users behind
>> a single IP. The first one to login with IP-based auth. Since IPv4 ran
>> out back in 2003 a number of networks have started using one layer.
>> Since 2010 when IPv4 stopped being readily available its become more and
>> more popular to use 2 and even 3 layers of NAT between any two machines.
>> Just so they can talk.
>>
>> Then there is this thing called DHCP. I guess this is what you mean by
>> one user taking over anothers IP. Since the DHCP service allocates any
>> available IP to user devices on request. If a device goes away its IP
>> can get re-used immediately by another device. Its uite difficult to get
>> Squid to be aware of any of those changes and update its auth
>> information.
>>
>> Then there is the thing called "privacy addressing". In IPv6 its
>> built-in, with IPv4 its done using DHCP short dynamic assignments. It
>> means the IP address assigned to user devices is guaranteed to change
>> frequently and randomly.
>>
>> Now, if your network can operate without NAT or DHCP, or IPv6. You are
>> one of the very rare lucky people for whom IP-shortcut based auth
>> *might* work. But only until you have a malicious user contact the
>> network and start spoofing users IPs.
>>
>>
>> IP address based authentication is, well. Dead.
>>
> Okay, well I know how NAT and DHCP works, so I guess I am one of those
> rare cases you talk about.  We have no NATs, I am only trying to use
> squid on a small section of our network which has statically assigned IP
> addresses and they have no admin rights to change it. They are open 24/7
> so some stranger walking in, plugging his laptop on our network and
> trying to figure out which IP is already authenticated is very unlikely
> since everybody knows each other and it noticed/reported. That's why
> this does not concern me. I was also only planning to have it remember
> the IP for maybe 1 hour.

Yes it would seem you are.

> 
> On the other hand, having users re-authenticate every time they close
> their browser would irritate them and possibly cause confusion as most
> of them are not very technical(It might just be something they will need
> to adjust to after all).

They will have to face it in every other authentication-related use of
browsers. So thay should not be a problem.

> 
> So in my case, either I figure out a way to go about this (I saw your
> suggestions below and am going to do some reading) or I might have to
> not implement any authentication at all, which I think is worse.

Yes and no.

The auth system is only a problem if you want user/browser to be the one
supplying credentials. For that Squid has to validate the users claim
about who they are and deal with incorrect/missing claims etc. The pop
is resulting from all that.

If you are happy to avoid user-supplied credentials entirely you can use
an external ACL helper that takes %SRC (the client IP) and provides
Squid with "OK user=username" with the username to log about who is
supposed to be using that machine IP or "ERR" for unauthorized access.

Incidentally that IP->username mapping exactly what the ip_shortcut 2.7
feature used to do. But without any possible way to control on your part
about what usernames were supplied for which IP.


These two helpers are provided with Squid that do this for different
backend databases of IP->user mapping:

<http://www.squid-cache.org/Versions/v4/manuals/ext_edirectory_userip_acl.html>

<http://www.squid-cache.org/Versions/v4/manuals/ext_sql_session_acl.html>

The SQL one is what I use for my own clients when they have an office
setup like you describe and a very stable / long term group of trusted
workers.

Amos