[squid-users] IP based user identification/authentication

Andrey K ankor2023 at gmail.com
Fri Dec 8 05:59:54 UTC 2023


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 at 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 <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/20231208/497e7cf2/attachment.htm>


More information about the squid-users mailing list