Impersonating someone who understands ASP.NET Web Service Security
Wednesday, I was briefly working on a web service to deal with a rare problem with KDocs document returns. I decided to write a utility that potentially would be available to domain users which would correct the situation after the fact. It would connect to the appropriate database server, confirm that the symptoms matched those known for this particular problem, and then correct it. That requires that the web service connect to the database as semi-privileged SQL user. The easiest way would be to use SQL authentication. However, I didn't think of that right away, and had decided to rely on an Integrated Security connection.
When you run the web service, your identity is the local ASPNET account. I got errors connecting with this identity.
The solution was:
<identity impersonate="true" userName="domain\priveduser" password="secret" />
The <identity> tag, a child of <system.web>, does not require the userName and password attributes. They are only required if you want to impersonate someone other than the caller.
Which brings me to my next lesson. The next morning, while riding the train, I worked on the very same project on my laptop. I was thinking that since only domain users should ever be able to invoke this web service that I should turn off Anonymous Access and leave only Windows Authentication enabled. The next time I ran the service (from my WinForms test application), I got an HTTP 404 - Access Denied error. And I struggled with this error for the entire ride. After all, I am in my laptop's local Administrators group. So what was it? At first I thought it was misset ACLs somewhere in the c:\inetpub tree. And indeed I did find entries for laptop\Pinsley that seemed to allow no access. But the problem persisted even after I corrected what I now perceive to be a red herring.
As I pulled into Grand Central, I came upon the solution. You have to explicitly set the network credentials on the web service proxy. The magic line was:
FixTool = new localhost.Fixer();
FixTool.Credentials = System.Net.CredentialCache.DefaultCredentials;
That did the trick. So if you want to disable Anonymous access to your web service, remember to set your credentials! Live and learn...
When you run the web service, your identity is the local ASPNET account. I got errors connecting with this identity.
The solution was:
<identity impersonate="true" userName="domain\priveduser" password="secret" />
The <identity> tag, a child of <system.web>, does not require the userName and password attributes. They are only required if you want to impersonate someone other than the caller.
Which brings me to my next lesson. The next morning, while riding the train, I worked on the very same project on my laptop. I was thinking that since only domain users should ever be able to invoke this web service that I should turn off Anonymous Access and leave only Windows Authentication enabled. The next time I ran the service (from my WinForms test application), I got an HTTP 404 - Access Denied error. And I struggled with this error for the entire ride. After all, I am in my laptop's local Administrators group. So what was it? At first I thought it was misset ACLs somewhere in the c:\inetpub tree. And indeed I did find entries for laptop\Pinsley that seemed to allow no access. But the problem persisted even after I corrected what I now perceive to be a red herring.
As I pulled into Grand Central, I came upon the solution. You have to explicitly set the network credentials on the web service proxy. The magic line was:
FixTool = new localhost.Fixer();
FixTool.Credentials = System.Net.CredentialCache.DefaultCredentials;
That did the trick. So if you want to disable Anonymous access to your web service, remember to set your credentials! Live and learn...
posted by Howard Pinsley at 6:27 AM
0 Comments:
Post a Comment
<< Home