Hello, Amos,
For more info lookup "captive portal" on how this type of configuration
is done and used.
Did you mean this link: https://wiki.squid-cache.org/ConfigExamples/Portal/Splash?
It seems to be very useful in my case.
Thank you very much!
Kind regards,
Ankor.
чт, 7 дек. 2023 г. в 18:40, Andrey K <ankor2023@xxxxxxxxx>:
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@xxxxxxxxxxxxx>: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@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
