On 2/10/2012 8:43 p.m., Eliezer Croitoru wrote:
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)
We do not have any formal criterion. Preferrably something portable,
well known and either commonly available or easily installable to ease
the job on disributors and testers. We so far distribute C++, perl, awk,
or bash code helpers. At the very least it needs to integrate cleanly
with auto-tools so we can actually build and bundle it.
The interpreted languages like Ruby, Python, Java, PHP etc are getting
close to being options, but I'm not sure whether the redistributors OS
distro systems are all up to the task of packaging them cleanly yet.
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?
Er, yes applying ACLs is not possible because Squid only contains ACLs
to test Proxy-Authentication: header values (proxy_auth ACL type). Which
is leveraged for WWW-Authenticate header values in reverse-proxy mode.
The external ACL interface is not registering credentials as such to
Squid, but making them available for Squid to use to authenticate an
outbound request as it goes upstream.
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?
The Squid bits by me. The latest round of kernel bits by Krisztian
Kovacs on netfiler-devel mailing list.
Amos
