5

I have an asp.net web application that makes calls to several WCF services. The web app is located at www.mydomain.com and the services are at services.mydomain.com. They are hosted from the same server.

I've just added secure endpoints (bassicHttpBindings) to the services that use Transport security (https) and Windows authenication:

<binding name="WindowsSecuredBinding">
  <security mode="Transport">
    <transport clientCredentialType="Windows" />
  </security>
</binding>

and configured the client web app to use these new secure endpoints. I was expecting the next step to be writing some code in the web app to set the client credentials in order to pass the Windows authentication. To my surprise, the service calls are succeeding without setting the client credentials. I'm assuming it must be sending the account that the web app is running under but don't know how to verify that. In other scenarios I thought I've seen the client credentials having no implicit default.

So I have two questions:

  1. How is authentication succeeding? Does it send the user the app runs under, the browser user's credentials, no credentials?
  2. How can I debug/log/trace the authentication process? I'd like to at least see the username that's being authenticated so I can validate the security.
xr280xr
  • 12,621
  • 7
  • 81
  • 125
  • Window-authentication uses [Kerberos](http://support.microsoft.com/kb/217098) IIRC. I believe it uses the Current Identity, but I am not sure how if it is configurable or how all the little details work. –  Oct 03 '12 at 16:24

1 Answers1

3
  1. With your current configuration as you have it on the server and client side the client is sending the creditials that it is running under. Because the credential type is set to Windows that causes the security negotiation to check in Kerberos if you are in a domain or in NTLM if it's a workgroup environment. (More information can be found here.)
  2. To debug the authentication process WCF has an auditing feature that can be enabled. Instructions for adding auditing are here.

Here's the important parts from the auditing MSDN page:

<behaviors>
 <behavior name="myAuditBehavior">
  <serviceSecurityAudit auditLogLocation="Application"
    suppressAuditFailure="false" 
    serviceAuthorizationAuditLevel="None" 
    messageAuthenticationAuditLevel="SuccessOrFailure" />
 </behavior>
</behaviors>

and adding the behavior to the service:

<service type="[Your service type here]" behaviorConfiguration="myAuditBehavior">

Once auditing is enabled you can see all the authorization activity (success and failure if you configure it that way). This should allow you to validate that your security is setup they way you would like it.

If you happen to need functionality of passing the credentials of the user that is using the ASP.NET web app (this is called Impersonation) the msdn documentation on that is found on this page "Delagation and Impersonation with WCF".

Phil Patterson
  • 1,242
  • 15
  • 25
  • Excellent answer. Thanks for touching on impersonation too. So am I correct in thinking myClientBase.ClientCredentials is already, by default, set to System.Net.CredentialCache.DefaultNetworkCredentials or is DefaultNetworkCredentials something else? Perhaps I will discover that on my own using auditing. – xr280xr Oct 03 '12 at 17:30
  • My guess is that it is set to the credentials of the app pool identity that your web app is running as (assuming that you are hosting in IIS). It's possible if the web site was already configured for impersonation that the WCF call is inheriting it (but I doubt it). Auditing will be the only way to know for sure, but I'm guessing it's the app pool identity. – Phil Patterson Oct 03 '12 at 17:35
  • The web app site is configured to allow anonymous access using the local IUSR_* account. It's using that account for authorization which is different from the app pool account. – xr280xr Oct 03 '12 at 22:30
  • I may need to create a test app to run through all the scenarios. MSDN indicates that you must turn on impersonation/delegation for the client credentials to be used instead of the domain account the service is configured to run as (though your test indicated otherwise). I wonder if there is a nice way to create a test domain I could use on my home network to work though the scenarios. I don't personally run a domain for my 3 PCs at home so it makes testing windows domain security problematic. – Phil Patterson Oct 04 '12 at 20:57