Re: mod_auth_kerb and Squid proxy
Hi, At 13.14 13/11/2006, Henrik Nordstrom wrote: For SPNEGO the interface is slightly more complex due to the multistage nature of the protocol. If you know Samba ntlm_auth --helper-protocol=gss-spnego then this is the helper protocol we use. This protocol is based on the protocol we designed for NTLM authentication helpers many years ago, but slightly different to adopt for the requirements of SPNEGO. REQUEST : RESPONSE: [] commands: YR Start of a new Negotiate/SPNEGO handshake. KK Additional handshake from the client responses: AF Authentication successful. The returned details indicate the username in ASCII or UTF-8 encoding (not UTF-16). TT Authentication not yet finished. Challenge or additional blob to send to the client. NA Permanent failure. Invalid credentials, request not understood, or some other permanent problem processing the request. Details contain an error message describing the condition. BH Temporary failure, for example communication error. * may be used as a placeholder for the spnego blob if no blob is available. As reference you could see the mswin_sspi negotiate helper for Windows, where the Windows native API access is almost isolated. As for Basic there is plans to introduce the tagged request/response format for these helpers as well, in which case the helper is expected to be able to handle multiple challenge/response channels identified by their tag, and optimally to be able to process multiple requests in parallel (at most one per channel). > Also I don't know > what is the situation on the client side and what HTTP clients provide > support for SPNEGO authN against proxies. I believe the Gecko-based browser > support that but not sure. It's not too bad these days I am told. MSIE since MSIC 7 supports it. Or at least the Vista version. All Internet Explorer 7 versions, XP, 2003 and Vista are using proxy SPNEGO. Current versions of Firefox also supports it, but maybe not enabled by default. Proxy SPNEGO support is enabled by default in Firefox and Seamonkey, while the HTTP SPNEGO support must be enabled. Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: icap in either squid-3 and squid-2
On Tue, 2006-11-07 at 10:32 -0500, Jeremy Hall wrote: > I'm trying to track down why the Content-Length header might not be > sent to the icap server in squid-2's implementation of icap. ... > I haven't tried this with squid-3 because I > don't want to manually upgrade my config file if the problem isn't > resolved. Can somebody give me some ideas on how best to proceed? If you tell me how to reproduce the Content-Length problem, I will try to check whether it still exists in Squid3. HTH, Alex.
Re: Squid-ICAP problem (bug?)
On Wed, 2006-11-08 at 16:26 +0100, Christophe Boyanique wrote: > I think I have found a bug in the Squid-ICAP patch and I would like to > have your opinion about it. ... > The problem is that the end of the chunk (0\r\n\r\n) is not sent (and > read) in the same stream that the beginning of the chunk. FWIW, the problem does not seem to be present in Squid3. The incremental chunked coding parser declares success only when the last-chunk followed by an optional trailer was found. I have not tested this though. Alex.
Re: mod_auth_kerb and Squid proxy
mån 2006-11-13 klockan 09:26 +0100 skrev Daniel Kouril: > this your mail got too burried too deeply in my mailbox, sorry for not > responding earlier. If you're still interested in the SPNEGO/Basic (krb5 > passwords verification) support, I'd be happy to contribute a code for Squid. > However, I don't know the code of Squid or have much time to learn it, so it > would be nice if you provided me with a more detailed description of what > needs to be changed and where I should start looking at. What we need is a helper application which understands the authentication protocol, nothing more. All the HTTP header stuff is managed by Squid. This helper process is running separate from Squid and is reading authentication exchanges on stdin and sending responses on stdout using a simple text based protocol. For Basic the interface is simply REQUEST : usernamepassword RESPONSE: OK/ERR[Error message] where username & password is URL-encoded. An alternative more effective protocol is also available where the requests/responses is prefixed by a tag binding the request and response uniquely together. REQUEST : tagusernamepassword RESPONSE: tagOK/ERR[Error message] in this format it's important the helper doesn't discard unprocessed input as there may be a long queue of requests waiting on stdin. This mode of operation is intended for helpers which can process multiple requests in parallel, but it also helps a lot for single request helpers as well as it allows Squid to queue multiple requests to the same helper instance. For SPNEGO the interface is slightly more complex due to the multistage nature of the protocol. If you know Samba ntlm_auth --helper-protocol=gss-spnego then this is the helper protocol we use. This protocol is based on the protocol we designed for NTLM authentication helpers many years ago, but slightly different to adopt for the requirements of SPNEGO. REQUEST : RESPONSE: [] commands: YR Start of a new Negotiate/SPNEGO handshake. KK Additional handshake from the client responses: AF Authentication successful. The returned details indicate the username in ASCII or UTF-8 encoding (not UTF-16). TT Authentication not yet finished. Challenge or additional blob to send to the client. NA Permanent failure. Invalid credentials, request not understood, or some other permanent problem processing the request. Details contain an error message describing the condition. BH Temporary failure, for example communication error. * may be used as a placeholder for the spnego blob if no blob is available. As for Basic there is plans to introduce the tagged request/response format for these helpers as well, in which case the helper is expected to be able to handle multiple challenge/response channels identified by their tag, and optimally to be able to process multiple requests in parallel (at most one per channel). > Also I don't know > what is the situation on the client side and what HTTP clients provide > support for SPNEGO authN against proxies. I believe the Gecko-based browser > support that but not sure. It's not too bad these days I am told. MSIE since MSIC 7 supports it. Or at least the Vista version. Current versions of Firefox also supports it, but maybe not enabled by default. We have also noticed Microsoft has introduced a "Kerberos" HTTP authentication scheme. The details of this scheme is still unknown to us, but we expect it to be raw GSSAPI exchanges not wrapped in SPNEGO. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
