<div dir="ltr">Hello, Amos,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For more info lookup "captive portal" on how this type of configuration<br>is done and used.</blockquote><div>Did you mean this link: <a href="https://wiki.squid-cache.org/ConfigExamples/Portal/Splash">https://wiki.squid-cache.org/ConfigExamples/Portal/Splash</a>?</div><div>It seems to be very useful in my case.</div><div>Thank you very much!<br></div><div><br></div><div><br></div><div><br></div><div>Kind regards,</div><div>      Ankor.</div><div><br></div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 7 дек. 2023 г. в 18:40, Andrey K <<a href="mailto:ankor2023@gmail.com">ankor2023@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello, Amos,<div><br></div><div>Thank you for your comments.</div><div>I must have described the scenario incorrectly, I'll try again in more detail.</div><div><br></div><div><br></div><div><div>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.<br><br>When a request comes to SQUID, and the policy reaches the rules where user information is required (for example "<b>http_access allow auth"</b>), an external helper must be called, and the src IP address would be passed to it.</div><div>The helper accesses the 

Awareness system and asks if it has information about the user registered on the host with this source IP address.<br><br>If the user is found, the helper must return his username to the SQUID. SQUID should assign this username to the <b>%LOGIN</b> variable. And then this session should be considered authenticated (for example, it should match the "<b>acl aclname proxy_auth username</b>" acls). Next, authorization helpers may be launched for it (for example, <b>ext_wbinfo_group_acl</b>) if necessary according to the policy.<br><br>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.<br><br>The described process is definitely not authorization, it is rather user identification. </div><div><br></div><div>I hope I've cleared things up a bit.</div><div><br></div><div>Kind regards,</div><div>      Ankor.</div><div><br><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 7 дек. 2023 г. в 13:39, Amos Jeffries <<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/12/23 15:34, Andrey K wrote:<br>
> Hello,<br>
> <br>
> I was interested if I can configure some custom external helper that <br>
> will be called before any authentication helpers and can perform user <br>
> identification/authentication based on the client src-IP address.<br>
<br>
Well, yes and no.<br>
<br>
<br>
<br>
The order of authentication and authorization helpers is determined by <br>
what order you configure http_access tests.<br>
<br>
So "yes" in that you can call it before authentication, and have it tell <br>
you what "user" it *thinks* is using that IP.<br>
<br>
<br>
However, ...<br>
<br>
> It can look up in the external system information about the user logged <br>
> in to the IP address and return the username and some annotation <br>
> information on success.<br>
<br>
Users do not "log into IP address" and ...<br>
<br>
<br>
> If the user has been identified, no subsequent authentications are required.<br>
> Identified users can be authorized later using standard squid mechanisms <br>
> (for example, ldap user groups membership).<br>
> <br>
> This feature can be especially useful in "transparent" proxy <br>
> configurations where 407-"Proxy Authentication Required" response code <br>
> is not applicable.<br>
<br>
<br>
... with interception the user agent is not aware of the proxy <br>
existence. So it *will not* provide the credentials necessary for <br>
authentication. Not to the proxy, nor a helper.<br>
<br>
So "no".<br>
<br>
This is not a way to authenticate. It is a way to **authorize**. The <br>
difference is very important.<br>
<br>
For more info lookup "captive portal" on how this type of configuration <br>
is done and used.<br>
<br>
<br>
Cheers<br>
Amos<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div>
</blockquote></div>