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 : username<space>password<nl> RESPONSE: OK/ERR[<sp>Error message]<nl> 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 : tag<sp>username<sp>password<nl> RESPONSE: tag<sp>OK/ERR[<sp>Error message]<nl> 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 : <command><sp><base64spnegoblob><nl> RESPONSE: <response><sp><base64spnegoblob|*>[<sp><details>]<nl> 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
