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 <ankor2...@gmail.com>: > 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 <squ...@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@lists.squid-cache.org >> https://lists.squid-cache.org/listinfo/squid-users >> >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
