Squid authentication - one login for multiple instances running on one or more servers possible?

I have just little experience with all of this "authentication stuff" to be honest. I have looked at the http://www.openldap.org website and it would take me days, if not longer, to digest all the necessary information. The eDirectory from Novell may be an overkill for what I need and it's priced per user (although reasonably in my opinion).

I feel like there got to be a simpler and more obvious solution? But if there is not, would someone more knowledgeable in this field be willing to find a solution for me, for a reasonable price? I am not sure if I am allowed to ask for such kind of help in here and if I am not, I apologize...

Tomas
tomfra[AT]centrum.cz

> I'd much prefer if the user had to login just once for both (or several) instances
Unfortunatelly it's browser problem. And since browser knows, that it swiched to new proxy, it will not use credentials from the first. I don't know how to tell browser that two different proxies(IP:port) are he same in fact.

You could present just one IP:port for users, then You could redirect it to different real proxies. It can be done with iptables or another load-balance service.
In such case browser would think it still connects to same proxy.

> On the same topic
As above.

ravenpl: this would solve the problem only partially in this particular case I am afraid... Some of the proxy servers will be at different locations (different countries) and I'd like to offer the users to choose which of the proxy server they prefer.

I believe the key here is to not use the basic authentication schema. Perhaps some solution where the user logs in which then creates a cookie on the user's computer which is then read by some external "squid helper" and passed to squid? But as I said, I do not know much about this stuff so I may be completely wrong. And I am not aware of such a solution at this time anyway...

Tomas

As I said - it's browser problem, not the proxy itself. It have to be solved on the browser side, or browser have to think it still uses same proxy.
Maybe You should provide very simple local proxy(connection forwarder), which would be installed locally on browser's box. It would do nothing but will redirect connection to desired real proxy. it would be configureable wihich real proxy it should use. This way browser will always use localhost:someport proxy, and therefore will reuse same auth credentials for any proxy.

That could be a solution, I'll think about it. But I realize there would be some drawbacks too - e.g. installing even a simple proxy software on the user's computer may be beyond technical skills of many users and there would need to be a MS Win & Mac OS X version of the proxy, some people have firewalls and/or company policies not allowing them to install a proxy server on their workstations etc.

I am sure there is a solution that does not need the "end users" to install anything on their PCs. I have found http://www.pubcookie.org for example but I am not sure if that would work with Squid at all or how to implement it, yet. Squid is apparently very flexible when it comes to authenticating but I feel it's extremely complex too.

Tomas

about pubcookie - isn't it installed on client's side anyway?

I am not against a solution that involves some kind of client software running on the user's computer as long as there is still way to authenticate using just the web browser in cases when it's not possible to install the client software. In other words, if the users have the client software installed, they have to login just once (or simply have the client software / daemon running). If they don't, they can still use the proxy servers - but they will have to log into each of them separately.

This is completely OK. However, if possible at all, there should be also a Mac OS X version of such software. I could probably have something like that coded though. A similiar approach, and I'd prefer that, would be authentizing the user through a public/private key pair. I.e.: If there is the right certificate installed on the client's computer, they are authomatically authenticated on all of the proxies. Since web browsers can have the certificates stored and can work with them directly, there would be no need for any client software. But as before, this is somewhat beyond my expertise so I may be wrong. But it would be a very "clean" and secure solution in my opinion.

Tomas

When researching futher this issue, I found references to "kerberos" - http://web.mit.edu/kerberos/ . From what I understood, it uses "tickets" to authenticate users which someone compared to public/private key authentication. I have also seen mentioned it as one of the auth. solutions for Squid, but with too few details given. Does anyone have experience with this "kerberos"?

Tomas

I see... OK, let's forget about Kerberos for now as it probably only complicates it.

But if there was a certificate installed in the web browser repository (or wherever they can be stored), allowing access to all the squid servers, wouldn't that solve the problem? I mean, when the user skips from one squid server to another I understand they got to authenticate again. However, if instead of a username/password prompt there was a check for the presence of the certificate, the authentication would be "automatic" and the user would not have to interfere with the process at all, right?

I accept the fact there may be no way than to authenticate at each of the servers separately. I just don't want the users to have to do all of the authentications by hand - e.g. by entering their username/password combo into a popup window. If the process takes place "in the background", I am fine with that.

Tomas

> the authentication would be "automatic" and the user would not have to interfere with the process at all, right?
Would have to choose the certificate to use. But it's way simpler than entering user/pass.
But - personally I don't know how to configure such thing.

OK, I have been thinking about something that would work for a *very* long time and I think I found it. I have yet to test it but I believe it will work. It's too late today, I will post the details tomorrow. Let's see if it actually will work ;)

Tomas

Whoops, the old identd port is a dead link. Sorry, but Retinascan still works. So does the version for 9x.

Heh, me again.... I forgot about your second half.

You need to setup a parent Squid cache server and make the others children or siblings.

Then in your squid.conf make sure you add the appropriate "cache_peer" lines.
See the Squid docs for more on setting this up. But basically the other servers will have to have a line something like:
cache_peer cache.parentbox.example parent 3128 3130

I also like to install Squidguard as well as Squid and setup s script to fetch and install the latest blocklists.

Later.

Hit somewhere like
http://www.visolve.com/squid/squid24s1/contents.php
For more Squid help.