Re: [squid-users] Authentication problem

OK, so here's another pseudo code that comes to my mind, this is
somehow similar to some commercial products (Ironport, bluecoat):

- The user connects to http://www.somesite.com via the proxy
- The Proxy redirects to
http://authenticationportal/http://www.somesite.com with 302 return
code.
- User is verified/authenticated on the authentication portal. This
authentication portal sets a cookie and redirects to
http://www.somesite.com
- User connects to http://www.somesite.com via proxy. Proxy knows user
is authenticated (cookie).

The problem is with the last step since the cookie is bound to
http://authenticationportal so the user may encounter an endless loop.

Do you know the solution for letting this authenticated user go to the
target after being authenticated

2012/4/3 Amos Jeffries <squid3_at_treenet.co.nz>
>
> On 3/04/2012 3:40 a.m., Mohamed Amine Kadimi wrote:
>>
>> Dear Developpers and Community,
>>
>> I would like to set up the following configuration using squid:
>>
>> When a user asks for a web page he is transparently redirected to
>> squid, where an authentication must be done before serving the user
>> with content.
>
>
> Please read
> http://wiki.squid-cache.org/SquidFaq/InterceptionProxy#Why_can.27t_I_use_authentication_together_with_interception_proxying.3F
>
>
>
>>
>> However, users IP are being NATed before going to the proxy. So the
>> solution would be to use an application-layer verification: cookies or
>> http headers
>>
>> So, I come across the following solutions:
>>
>> 1. Use an ICAP server which checks if a cookie is set, otherwise set
>> it for an authenticated user
>>  the problem is: cookies are bound to domains + each http request must
>> be validated
>>
>> 2. Use a php splash page which sets the cookie then redirect to destination
>>  same problem as ICAP
>>
>> 3. using squid authentication and checking if Proxy-Authorization
>> header is set before serving the client
>>   problem: sessions are associated to the IP by squid
>>
>> I'm using squid 3.1
>>
>> Thank you for any idea
>
>
> The whole point of transparent interception is that the browser is *completely unaware it is talking to a proxy*. It contacted some web server, and *all* of its communications are with that server. If you can find a way to trick it into storing security credentials of any kind set by your proxy it will consider those credentials safe to use when contacting the same server via other non-HTTP methods as well, causing great deal of problems. The good thing to do at that point is to report the zero-day security vulnerability you just found.
>
>
> You might be able to use details gleaned from the browsers request to *guess* what user it is and have a external_acl_type script inform Squid of the guessed username. Or the authorize (*not* authenticate) the request to happen.
>
> Amos

--
Mohamed Amine Kadimi
Tél     : +212 (0) 675 72 36 45