On 10/2/2012 8:55 AM, Amos Jeffries wrote:
On 2/10/2012 4:45 p.m., Eliezer Croitoru wrote:
The current authenticators for squid using ntlm\kerb etc but based on
forward connection to the proxy.
how about using 802.1x authentication to radius? what i mean is as
transparent authenticator that dosnt require the user to configure
something in his browser but just connect the cable to the network and
the rest will be done by the dhcp+radius+some helper?
Supported. Although we do not bundle a helper for it. (Contributions
welome).
any specific language ?
(since I wrote a nice framework in ruby that can take lots and lots of load)
That rides the fine line between authentication and authorization - and
the other fine line whether it is validating a machine client or a user
client. HTTP authentication requires the credentials to be contained
within the HTTP message itself, otherwise one cannot guarantee that the
client sending the message is the client originating the message. For
example all requests coming out of your Squid would be from a RADIUS
authenticated machines, but what user account gets credited? two
requests on the same TCP connection relayed through another proxy before
they arrive has the same issues.
Squid external ACL is the interface for side-band authorization to
permit/deny through Squid based on some non-credentials criteria
(possibly the side-band 802.1x information). With user= password= helper
response keys it can be used to assign Squid some credentials for real
authentication with down-stream servers on the clients behalf. Even then
that still rides the fine line as to whether it is machine client,
software client or user client credentials being used.
Amos
I do understand the difference between authentication and authorization.
the point in my case is that we are talking about a user account rather
the user itself like In ISP environments.
In ISP environment the user authentication is done per
connection\session and not per request.
Let say the ISP has some radius server that serves
cisco\juniper\microtik NAS for PPPOE\L2TP\PPTP\SSTP incoming connections
to authenticate the users login.
In this case the username is assigned IP from the pool and will only be
removed in the case where the session\connection is terminated (usually
after 2*10 echo interval) which makes about 1 minute max for the radius
to get update from the NAS to remove the ip->user entry.
So as for the helper it's pretty simple query of IP from a DB and since
I already kind of wrote an external_acl\helpers framework with
concurrency support it only matter of how to implement it which is nothing.
since I am talking about ISP everything is per IP + MAC address ->username.
if anyone wants to get other user credentials for now he will need to
disconnect from the system.
I am planning to put together some mechanism that will allow a user to
identify himself to the system using some web page.
By the way in ipv6 era since every internet client can get a subnet it
can give to the IP level of things a wider band of options.
so for now I have a question.
If an external_acl returns the username to squid on the http_access line
and has ttl=30 then squid complains about that intercept dosn't support
authentication and will not apply any internal acls for identity but, is
it suppose to send to ICAP service (like it logs in the access.log) the
username?
I have a more technical question about TPROXY(sockets programming) not
related to this directly, who is the guy that did all the TPROXY stuff?
Thanks,
Eliezer
--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
