[squid-users] IP based user identification/authentication

[Andrey K]

Hello, Amos,

Thank you for your comments.
I must have described the scenario incorrectly, I'll try again in more
detail.


Let's say we have a system that collects information that a user logged in
to a computer (it can, for example, read security logs from Active
Directory). Thus, it has a match of the user's login and the host's IP
address. Let's call it Awareness system.

When a request comes to SQUID, and the policy reaches the rules where user
information is required (for example "*http_access allow auth"*), an
external helper must be called, and the src IP address would be passed to
it.
The helper accesses the  Awareness system and asks if it has information
about the user registered on the host with this source IP address.

If the user is found, the helper must return his username to the SQUID.
SQUID should assign this username to the *%LOGIN* variable. And then this
session should be considered authenticated (for example, it should match
the "*acl aclname proxy_auth username*" acls). Next, authorization helpers
may be launched for it (for example, *ext_wbinfo_group_acl*) if necessary
according to the policy.

If there is no information about the user in the external system and
additional authentication helpers are registered in the proxy configuration
(for example, auth_param negotiate program negotiate_wrapper_auth), then
SQUID should return a 407 response and use basic/ntlm/negotiate
authentication methods as usual.

The described process is definitely not authorization, it is rather user
identification.

I hope I've cleared things up a bit.

Kind regards,
      Ankor.



чт, 7 дек. 2023 г. в 13:39, Amos Jeffries <squid3 at treenet.co.nz>:

> On 7/12/23 15:34, Andrey K wrote:
> > Hello,
> >
> > I was interested if I can configure some custom external helper that
> > will be called before any authentication helpers and can perform user
> > identification/authentication based on the client src-IP address.
>
> Well, yes and no.
>
>
>
> The order of authentication and authorization helpers is determined by
> what order you configure http_access tests.
>
> So "yes" in that you can call it before authentication, and have it tell
> you what "user" it *thinks* is using that IP.
>
>
> However, ...
>
> > It can look up in the external system information about the user logged
> > in to the IP address and return the username and some annotation
> > information on success.
>
> Users do not "log into IP address" and ...
>
>
> > If the user has been identified, no subsequent authentications are
> required.
> > Identified users can be authorized later using standard squid mechanisms
> > (for example, ldap user groups membership).
> >
> > This feature can be especially useful in "transparent" proxy
> > configurations where 407-"Proxy Authentication Required" response code
> > is not applicable.
>
>
> ... with interception the user agent is not aware of the proxy
> existence. So it *will not* provide the credentials necessary for
> authentication. Not to the proxy, nor a helper.
>
> So "no".
>
> This is not a way to authenticate. It is a way to **authorize**. The
> difference is very important.
>
> For more info lookup "captive portal" on how this type of configuration
> is done and used.
>
>
> Cheers
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20231207/1787e313/attachment.htm>