http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Go to http://ayende.com/blog/postdetails/details. It throws an exception. Fix needed or disable link.http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment13http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment13Sat, 24 Dec 2011 09:15:42 GMTMichael, The problem is, I _don't_ see an Authorization header in the first request that fails.http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment12http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment12Fri, 23 Dec 2011 10:02:46 GMTAfter looking into it, I believe that the behavior is correct, and is an artifact of the integrated NTLM handshake. read: http://www.innovation.ch/personal/ronald/ntlm.html The empty requests, in their `Authorization` header, contain a "Type-1" message (see above article), which EXPECTS a response with a "Type-2" message, before the final request for the resource can be made with the result of the NTLM handshake, the "Type-3" message. If you point the sample application at IIS, after setting up a `public` virdir with only `Anonymous Authentication` enabled and a `secured` virdir with only `Windows Authentication` enabled, you will see the NTLM handshake occur for the `public` resource, even though anonymous access is allowed, because the `Authorization` header is present, with a "Type-1" message, i.e.: C -> S: PUT ... Authorization: Negotiate ... (Type-1) Content-Length: 0 S -> C: 401 Unauthorized Authorization: Negotiate ... (Type-2) C -> S: PUT ... Authorization: Negotiate ... (Type-3) ... has request body S -> C: 405 Method Not Allowed (Expected, as I did nothing but setup a virtual directory.) So, as you can see, it still did the complete NTLM handshake, even though the request method is not allowed by the server. Setting `PreAuthenticate` to `true` allows the client to skip the challenge part of HTTP authentication to determine which authentication protocol to use, but it does not allow the client to skip any handshaking that is built into the authentication protocol itself.http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment11http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment11Thu, 22 Dec 2011 21:51:18 GMTAyende, 1) Correct, it does not send the "Expect" header. However, IMHO, the HttpWebRequest *could* have use it to probe for authentication and continue with the body if the server responded with "100 Continue". 2) On my traces, the *first* request to the "public" URI (after a successful request to the "secure" URI) contains a "Authorization: NEGOTIATE xxx" header. The HttpWebRequest is doing this because it assumes the authentication method is the same as for the "secure" URI. Mike, Unfortunately, the Web API HttpClient uses HttpWebRequest underneath, so the behavior will be the samehttp://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment10http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment10Thu, 22 Dec 2011 15:56:56 GMTPatrick, Yes, we had a bug with regards to time zone, that will be fixed nowhttp://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment9http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment9Thu, 22 Dec 2011 14:50:09 GMTSame issue with WCF Web API (expected) - http://wcf.codeplex.com/workitem/135 Also trying to solve this problem, thinking of adding something like Z-Authorizaion header that will do the job. However this is dirty solution. http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment8http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment8Thu, 22 Dec 2011 14:36:03 GMTMarcelo, a) on the first request, you don't know if the auth is there or not, so you submit with the request body. b) the actual problem is on the _second_ request, not on the first onehttp://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment7http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment7Thu, 22 Dec 2011 14:08:37 GMTNor sure if I follow you then: The FIRST time a request is, well... requested, the client can not know the authentication method. So it has to do TWO requests (empty one, with body the second). After that, all the requests are done as a single request. That works for secure urls. Now, for public urls, since the system doesn't has a way to know if the url will be public or private in advance, it has to use the same algorithm. There is where things break. But you are telling the system to do so by instructing it setting the PreAuthenticate to true. Set the PreAuthenticate to "secure" and you should not have to have any problems.http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment6http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment6Thu, 22 Dec 2011 13:47:56 GMTMarcelo, Sure it know, it remembers that from the last time. If that has changed, it would get a 401 and recoverhttp://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment5http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment5Thu, 22 Dec 2011 13:36:40 GMTIt can not send the authorization header as the header will depend on the authentication method. And of course, until you get the 401 www-authenticate, you can not know what authentication method (the framework) will have to use. The Expect should solve that, but since it is not the way the framework works...http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment4http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment4Thu, 22 Dec 2011 13:33:41 GMTPedro, 1) It doesn't send an Expect 2) It _doesn't_ send the Authorization header. What it does is send a request expecting to get a 401 with the WWW-Authenticate detailshttp://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment3http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment3Thu, 22 Dec 2011 13:01:28 GMTJust trying to complement your post: 1) HTTP already contains support for optimizing requests with body that may fail due to authentication requirements - see http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3 2) In the above example, when accessing the public URI, the client *assumes* that NEGOTIATE authentication is required. Due to this, it immediately sends the first NEGOTIATE client message without a body, since another protocol round will be required. The reason for this assumption is described on the msdn docs http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.preauthenticate.aspx, namely "After a client request to a specific Uri is successfully authenticated, if PreAuthenticate is true and credentials are supplied, the Authorization header is sent with each request to any Uri that matches the specific Uri up to the last forward slash". If you change the URIs to "http://gaviao:8080/secure/" and "http://gaviao:8080/public/" (note the ending slash), the problems does not occur.http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment2http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment2Thu, 22 Dec 2011 11:40:39 GMTBlog related bug report: The previous link at the top of the page links to the current page, instead of to the "Stupid smart code: Solution" post I expected. The blog posts "Stupid smart code: Solution" and "Stupid smart code" do a similar thing (link to themselves). Didn't check any further.http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment1http://ayende.com/149505/mixing-integrated-authentication-and-anonymous-authentication-with-preauthenticated-true-doesn-t-work#comment1Thu, 22 Dec 2011 10:34:00 GMT