We have a WCF web service that takes a "username:password" Authorization header. This service works fine on my development Windows 7 machine and on a Windows Server 2003 machine in production.
However, our development and new production servers are Windows Server 2008 and the service fails to receive the Authorization header.
You can see the raw request from Fiddler below includes the Authorization header.
POST http://servername/service.svc/soap HTTP/1.1
Content-Type: text/xml; charset=utf-8
Authorization: test:test
VsDebuggerCausalityData: uIDPozpQ7mbpOVRFu79Tl0h3mkIAAAAAJMavDzJlIkqyjJDSIIxdVuKNB0y6n29OvukFtyRt0wwACQAA
SOAPAction: "..."
Host: servername
Content-Length: 152
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
I haven't successfully enabled IIS Advanced Logging to see if I can get any extra information on the server.
The IIS website is configured for anonymous authentication.
The service implements IAuthorizationPolicy and the Evaluate method is definitely being called, which is where the authorization information is missing.
It feels like I've misconfigured something in IIS, but I have no idea what! Any help would be much appreciated.
It turns out I was dealing with two different problems.
On the development server, I found that the .NET 4.0 installation was broken. This was diagnosed by this brilliant tool.
On both servers, I changed the pipeline mode from Classic to Integrated, as nobody knew why it was set to Classic in the first place. A few tweaks the web config later, and the service was working!
The solution may also have required Basic Authentication, as suggested by Richard L, since that was missing from the production server. Note that Basic Authentication is not enabled on the service web site itself.
A very frustrating few days trying to get this working.
Related
I have a SOAP WCF service hosted in IIS and it is consumed by another company SAP system and everything was working fine for couple of years until our security team implemented Header validation in request and it stopped working all of sudden since the client SAP system request doesn't contain header CallingType. So then they added CallingType and pushed request to our system and F5 server allowed access and request entered to our system where WCF hosted. But WCF did not logged request and no data we got. So i would like to know how i can troubleshoot and provide fix. My network team is telling request is validated and passed by F5 server and pushed to our server. But why WCF is not logging anything??Do i need to add any custom header in webconfig of WCF service, or our IIS is preventing something? How can i see IIS is blocking the request.
I'm using an application that sends SOAP requests (HTTP POST) to my application running in CloudBees PaaS (run#cloud). The SOAP sender application gets the following error from the server: Transport error: 411 Error: Length Required. This means that it should not use chunked transfer encoding, because chunked doesn't send Content-length header which the server seems to want.
Is there some reason why chunked cannot be used? I'm aware that some web servers, like Apache, might have DOS vulnerabilities related to chunked transfer encoding. Is this the reason? Or is it because run#cloud uses Nginx as a proxy?
You can now set the httpVersion end to end for your app:
To enable: httpVersion=1.1
for example, this is how WebSocket works:
https://developer.cloudbees.com/bin/view/RUN/WebSockets
You can and should also set proxyBuffering=false - (this is default for new apps).
Cloudbees Nginx router indeed uses http 1.0 so don't have chunked transfert support. As we are working on websocket support, with a new version of NGinx, this may be available soon
I have a WCF service with webHttpBinding binding that works fine in Visual Studio 2010 / local IIS. The service has only one POST method that my separate web app project invokes via .NET's HttpWebRequest object. JSON is used for request and response. Request and response contain objects translated into and from JSON by DataContractJsonSerializer.
Once I deploy the service to a different Windows Server 2008 R2 machine on the same network, it generates "400 Bad Request" in response to the exact same calling code that works fine locally. By "calling code" I mean my web app running in Visual Studio.
No problems viewing the .svc file via a browser.
The request is less than one kB so it doesn't seem like size is an issue. Just in case I also tweaked the service's Web.config to allow for larger requests but that hasn't helped.
Resolved this shortly after posting question. Should clear things up.
My Cisco RV220W got confused. It wouldn't route the request properly, but the nature of what exactly it was doing and why the behavior was intermittent is beyond me. Rebooting it solved my problem.
I have to consume 3 web services (Sharepoint/Alfresco/Documentum CMIS) via WCF with HTTP Basic auth.
With Sharepoint or Alfresco, first request goes without Authorization header, receives HTTP 401, gets auto-retried by WCF with header, everything's fine.
But with Documentum, I receive HTTP 500 and a SOAP Fault instead, so WCF never gets an opportunity to send the header and returns the exception as-is.
I can of course add the headers manually via HttpRequestMessageProperty, but this looks like an ugly hack to me. Is there anything that could be configured on the WCF side to send headers with the first request, or on Documentum side to return 401?
You could try fronting the Documentum service with another web server that behaves properly, and passing the requests through?
I implemented something similar using IIS to front Apache Tomcat in order to use Windows Auth, and used the isapi_redirect.dll filter to pass requests through. More information about that can be found here: http://tomcat.apache.org/connectors-doc/reference/iis.html
Don't know if something like that is an option for you, but it may provide an easier solution in code.
Can anyone give a clear explanation of the difference between using
clientCredentialType=Windows, and
clientCredentialType=Ntlm
in a server-side Web.config when hosting a WCF service?
I have a SOAP 1.1 (basicHttpBinding) service for interop with existing clients. It uses ASP.NET roles so needs clients to be authenticated.
When I am using the VS2005 (Cassini) server to host the service, I have to specify ClientCredentialType=Ntlm as above, and check the Ntlm authentication box in the project properties in VS2005. ClientCredentialType=Windows doesn't work - clients get a:
401 Unauthorized error
However when I'm running under IIS, it's the other way around: ClientCredentialType=Windows works, and ClientCredentialType=Ntlm fails.
Can anyone explain this, and preferably suggest a way I can have the same web.config file to run the service in Cassini and IIS?
Update
I have .NET 3.5 SP1 on my dev machine, which is XP SP2 running in a domain. Cassini therefore runs under a domain account, and IIS 5.1 under a local account.
I wonder if it could be related to the breaking change in .NET 3.5SP1 described in these articles.
http://www.aspnetpro.com/newsletterarticle/2008/12/asp200812ab_l/asp200812ab_l.asp
http://msmvps.com/blogs/alvin/archive/2008/11/14/net-3-5-sp1-breaking-change-to-wcf.aspx
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=354236
The situation sounds similar as clientCredentialType=Windows fails when the server is running under a domain account (which is my situation with Cassini - running as my normal domain user account), and works when running under a local account (which is my situation with IIS).
The problem is that the suggested fixes require changes to a WCF client configuration file - but in my case I'm using SOAP 1.1 (basicHttpBinding) with non-WCF clients.
clientCredentialType=Windows uses the built in Windows authentication which can be through Active Directory and NTLM.
Obviously the NTLM type will only use NTLM for authentication.
I'm sure you've seen it already, but here is a link to WCF security:
http://msdn2.microsoft.com/en-us/library/ms734769.aspx
Some more details on your setup would help. Are the IIS and Cassini servers running on the same box? If not do you have the same accounts setup on each box? IIS6 by default supports NTLM, so you shouldn't have a problem getting it to work.