Peter -
I want to thank you for that thorough response.
I kind of suspected that was the case. Sometimes you have to read a RFC a
few hundred times to translate from theory to practical use. I had made
mention (to the authors of the server) that no challenge was being issued.
Unfortunately, especially in the industry that I am in, not responding (and
just closing the connection) in the absence of proper credentials is very
common. It prevents an accidental or deliberate probe of a URL from
divulging information that can be used to mount a subsequent attack.
The hack that you included below is similar to the one I did myself. I
merely put it in a method of a utility class rather than one of a derived
class.
- Patrick
"Peter Huang [MSFT]" <v-******@online.microsoft.com> wrote in message
news:XH**************@cpmsftngxa06.phx.gbl...
| Hi Patrick,
|
| The reason you are not seeing the credentials passed on the
| inital request to the web server is because Microsoft is following
| section 2 of RFC 2617(
http://www.faqs.org/rfcs/rfc2617.html)
|
| Here’s the main benefit of using pre-authenticate. Suppose I’m going to
| make 50
| requests to <http://server/path/> and this URL is protected with Basic
| authentication. On the first request, the client gets challenged by the
| server and
| sends back a second request which contains information that the server
| accepts
| (assuming auth succeeds) so it can send back the requested resource.
| With the pre-authenticate property set to true:
| The remaining 49 requests will include the authorization information in
the
| first
| request they send to the server so the server will not challenge the
client
| and
| force it to do another round trip before getting the resource.
| The total number of roundtrips between client and server will be 51.
| With the pre-authenticate property set to false:
| The remaining 49 requests will not include the authorization information
in
| the
| first request and will therefore be challenged by the server on each first
| request
| and will only get the desired resource after sending the authorization
| header in
| the second request.
| The total number of roundtrips between client and server will be 100.
| In other words, pre-authenticate=true is one request shy of taking half
the
| time of
| pre-authenticate=false. Note that pre-authentication only works for Digest
| and
| Basic in v1.0. It can’t work for NTLM because it is connection-based
| however the
| fact that it is connection based means that you’ll only get challenged
once
| per
| connection so it isn’t an issue if you are caching connections. In the
| Whidbey
| release of the .NET Framework we’ll also support pre-authentication for
| Kerberos.
|
| In order to get the inital request to send credentials, you will need to
| use the
| workaround of overriding the GetWebRequest method in the proxy code.
|
| (Hack code obtained from the Internet)
| The PreAuthenticate property on .NET's
| System.Web.Services.Protocols.SoapHttpClientProtoc ol is supposed to force
| the SOAP
| client proxy to send credentials with the first request, rather than doing
| the
| challenge/response exchange. If you add the following code to your SOAP
| Client
| proxy, you can make PreAuthenticate work (this example is for basic
| authentication):
| protected override System.Net.WebRequest
| GetWebRequest(Uri uri) {
| System.Net.HttpWebRequest request =
| (System.Net.HttpWebRequest)base.GetWebRequest(uri) ;
| if (this.PreAuthenticate) {
| System.Net.NetworkCredential nc =
| this.Credentials.GetCredential(uri,"Basic");
| if (nc != null) {
| byte[] credBuf =
| new System.Text.UTF8Encoding().
| GetBytes(nc.UserName + ":" + nc.Password);
| request.Headers["Authorization"] =
| "Basic " + Convert.ToBase64String(credBuf);
| }
| }
| return request;
| }
|
| This work around modifies the web service proxy class which is
| automatically generated. This means every time someone updates a "web
| reference" in
| Dev Studio, they would need to reinsert the "hack" code.
|
| Let me know if you have any questions or conerns.
|
| Regards,
| Peter Huang
| Microsoft Online Partner Support
| Get Secure!
www.microsoft.com/security
| This posting is provided "as is" with no warranties and confers no rights.
