views:

5202

answers:

4

I have an ASMX web service (on my localhost - WinXP IIS 5.1) that I call from a webclient. My webservice must consume another ASMX web service (on a Win 2003 server IIS 6.0).

When I provide credentials in my webservice code in a "hard-coded" manner:

engineWSE.Credentials = new System.Net.NetworkCredential("myUser", "myPass", "myDomain");

...the subsequent invoke of the remote web service works fine.

Now I am trying to impersonate myself in some initial testing. My initial reading on this tells me this can be a big subject but here is what I've done for starters:

  1. UNCHECKED "Anonymous access" in my virtual directory for the WebClient site on my localhost

  2. in web.config of my webclient site, I established: authentication mode="Windows" and identity impersonate="true"

  3. in the webmethod of my webservice that has to call the remote service, I changed to:

    engineWSE.Credentials = System.Net.CredentialCache.DefaultCredentials;
    
  4. When the remote webservice gets invoked with these DefaultCredentials, I get the following error:

    System.Web.Services System.Web.Services.Protocols.SoapException: Server was unable to process request.--->

    System.Net.WebException: The request failed with HTTP status 401: Unauthorized.

    at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse (SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)

    at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)

I am not sure whether I have misunderstood and tried to over-simplify "Impersonation" or whether the remote webservice is somehow wired to only accept credentials with 3 arguments (i.e. username, password, domain).

+1  A: 

Have you used netmon or wireshark to make sure the credentials are getting passed? What's the log on the service provider telling you? Also, make sure there's no impersonation tag configured in web.config (or other .config).

EDIT:

A HostingEnvironment.Impersonate() block perhaps -- that utilizes the app pool's identity by default, or the identity of any user token you pass it.

andrewbadera
Thanks for the answer and comment below. At this point, all I really know is there is no impersonate tag in any web.config (other than <identity impersonate="true"/>. I will investigate your additional suggestion.
John Galt
@unknown - you can set the user credentials to impersonate: http://msdn.microsoft.com/en-us/library/xh507fc5(VS.71).aspx. See the third grey box example.
Michael Kniskern
A: 

According to the following MSDN article, it will not work for HTTP and FTP protcols. You will have to explicitly provide the credentials when you make a connection to the remote server.

Michael Kniskern
Thanks for the article reference. I too see what you mean but I suspect I am just not understanding enough here (i.e. I believe there must be some way to exploit Windows authentication in an intranet environment and pass thru to another server (also in same domain as calling service and webclient).
John Galt
@unknown - Did you set your virtual directory to Integrated Windows authentication
Michael Kniskern
A: 

@ Michael Kniskern - It is certainly possible with HTTP. The impersonate feature will pass the credentials from the ASP.Net app to IIS. With Integrated Windows Authentication, the end user's credentials will then be used instead of the default ASPNET account (or account attached to the App Pool). That MSDN article's mention to HTTP and FTP was directed at DefaultNetworkCredentials, I believe.

A: 

@John - Were you ever able to get this to work for you? When I look at the DefaultCredentials via Debug, they are empty. If I look at the CurrentPrincipal for the current Thread, it shows the user that I authenticated to IIS with. My issue is the same as yours, I'm using impersonation (hence the thread context), however I'm unable to initiate a web request to the backend service which also requires the user's credentials to allow access to the backend resources.

Most people have conflicting results. It almost seems like I would need to do the authentication myself, cache the credentials and use them down stream, however, if they are calling my front end webservice to get to the back end webservice, it's even worse.

Thanks, George