Accessing remote web service from IIS Express results in 403 forbidden

Question

When I attempt to connect to an intranet web service from a web application running on IIS Express that web service returns a 403 Forbidden . The service works correctly when I access via unit tests or from the same site running on Cassini or on under IIS 7.5 on my server. My gut tells me this is a configuration issue, but I'm not sure where to begin looking.

What would cause a remote web service to return a 403 Forbidden when that service is accessed from a site running on IIS Express?

To clarify the service I am accessing is not SOAP based. I am setting up a specific network credential and passing it along with my request which the below code illustrates.

protected XDocument Search(Uri requestUri)
{
    var nc = new NetworkCredential(this.config.ServiceUserName,
        this.config.ServicePassword);
    var cCache = new CredentialCache();
    cCache.Add(requestUri, "Basic", nc);

    var request = (HttpWebRequest)HttpWebRequest.Create(requestUri);
    request.Credentials = cCache;
    request.PreAuthenticate = true;
    request.Method = WebRequestMethods.Http.Get;

    var response = (HttpWebResponse)request.GetResponse();
    return XDocument.Load(new StreamReader(response.GetResponseStream()));
}

Answer 1

List of issues you are/will be running into in case of Windows Auth on the Web services' side:

• as Cheeso pointed out your reqest could be simply running under anonymous (or local) account. This could be either due to running without impersonation of calling user and process itself runs under wrong account or user is considered to be anonymous and request is switched to that special local "anonymous" account.
• when you fix above by turning on impersonation of incoming user you'll run into "NTLM one hop hell" issues - incoming credentials can't be used on other servers (Kerberos is a solution, but unlikely to be available in most cases).
• when you fix first issue by disabling impersonation (or running code under process' account instead of incoming user's account) and making process to run under domain account (or other account that actually have permissions to the web service) you'll run into the fact that you may be opening possibilities for users to obtain data that thay should not have access too.

Essentially you need to figure out what account can/should access the web service and run code that acceesses the web service under that account. The account must log in locally (can't use identity of incoming user).

Answer 2

I do not have time to dig into the why right now, but I can say that it had something to do with my proxy settings. Switching to a different proxy provider for my box alleviated the issue. This internal transaction should have been bypassing the proxy all together and why IIS would behave differently than other mechanisms is beyond me. Begrudgingly I am going to mark this as the answer and hope the small notice to check your proxy settings helps someone. Sorry this isn't more specific.