Jenny Lee wrote:
Hello Amos,
Thank you for the reply.
Jenny Lee wrote:
Hello Folks,
Basic authentication. Same user must use different usernames from
the same IP in quick succession for role determination purposes.
This breaks the model and purpose of authentication. You apparently
are trying to use diffrent credentials for authentication and for
authorization and do do both simultaneously.
The regular way to do this is to assign a group indicating role to
the credentials. This gets tested to authorize particular actions
separately by the authenticating software based on the credentials.
Why can't you do it that way?
Why should username authentication must be bound for IP address of
the user.
It's not. Authentication is bound to an object request.
Assume that you have 3 people in an office all going out from the
corporate firewall. You have no control how they go out or for that
matter you have no control over anything except tehir user/pass. They
all do basic username authentication from the same IP. All 3 connects
at the same time. One authenticates. Why should the rest be accepted
whether their password is valid or not?
They are not. In HTTP every single request needs authentication
credentials added by the browser. Those credentials are what is used for
that single request ins stateless way.
For example; persistent connections to servers from a proxy can have
multiple users sending requests interleaved over it with different
credentials.
More importantly, why should the first one's username show up
everywhere in ACLs while the rest are browsing with their usernames?
Such behaviour is a HTTP violation. This only happens with a
misconfiguration.
What you are describing is the violation behaviour created by using the
authenticate_shortcircuit_ip hack. Which forces Squid to make a
stateful link between IP and user credentials. The first set of
credentials received are used instead of challenging following requests
which are missing credentials. ie the second and third user to try and
access never get challenged to add their own usernames to their requests.
This works fine, user can specify a new username and login with
that. When I left these values at defaults, user would specify a
new user/pass, but squid was still using his old user in its
operations.
The problem is: squid acceps the old password of the new
username. For example, if I type user1/pass1, browse, close
browser. Open, type user2/pass1, access is still granted. What is
controlling this?
Quite simple: * Squid keeps a list (cache) of credentials
previously seen. Along with the time they were last checked. * when
new ones come in they are looked for in the cache. * If they are
found and credentialsttl has not passed, the new ones are accepted
without testing. * If credentialsttl has passed, they are tested
with the backend again.
Well, exactly. So in that scenario, wouldn't NCSA helper return an
error when the client is using a different password?
If that username/password was invalid the client would be challenged to
provide new ones. This is logged as a 407 status.
If I leave authenticate_cache_garbage_interval at default value
(authenticate_ttl 2 sec, credentialsttl 1 sec), old username shows up
in logs and in ACLs.
When I keep: authenticate_cache_garbage_interval 1 second
The client is not accepted with the old password. He is forced to
enter correct password. So far so good. However, the old username
shows up in logs and ACLs!!!!
So I really could not figure out what to do.
I think you need to look for any configuration settings starting with
authenticate_ip_shortcircuit* and remove them or turn them off explicitly.
Once that is done see if the other setting start to work properly. If
not we will need to see all your squid.conf file (without the comment
lines).
Here is what I want to do:
Connect to my cache from my computer with basic authentication. Enter
user1/pass1. Close-open browser. Enter user2/pass2. I want in both
instances the correct user/pass pair be checked and correct user
logged and used in ACLs. What would the proper values of these
variables should be or which ones must be left at default?
It does not matter. None of these settings alter what the browser-sent
HTTP headers contain.
And what does 0 seconds do for these?
Makes the credentials sent in every single request go straight to the
backend authentication helper.
On a side note, is there a counter ACLs like acl random? For example,
say CONNECT method is matched, value of counter acl is incremented.
This way I can stop a user from doing more than say 50 connects a
day.
Not as such. You can easily create an external ACL script that takes in
the user details and method type and replies OK/ERR based on your criteria.
Thank you for the detailed information. Your knowledge is immense.
Unfortunately, being totally my fault, I am more confused than when I
started.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.5
