The application is not expecting ASP.NET to impersonate the calling user. I
will once again restate my problem. This has absolutely nothing to do with
my WSE UsernameToken and everything to do with Asp.Net impersonation and
connecting to SqlServer with Integrated Security.
In my Web Service application I’ve set <identity impersonate="true" /> in
the web.config. *I can successfully call my database with Integrated
security from anywhere in my web services.* On some of my webservices I
require user authentication. A username and password are sent to my
UsernameTokenManager derived class. Inside that class is an overridden
method named AuthenticateToken. It takes a UsernameToken object and expects
a string back. That string should be the password for the given user. WSE
then verifies that the password passed in matches the one returned from
AuthenticateToken.
I have all my usernames and passwords in a database table called users. It
has a column called username and one called password. My AuthenticateToken
method essentially returns “Select password from users where username = “ +
UsernameToken.Username. This query is also run with Integrated Security.
The big difference is that it is *not* using Impersonation like the rest of
the code in my Web Service application. Instead of running with
MyDomain\MyPrivelegedUser like _all_ my other web service code, it runs with
'NT AUTHORITY\SYSTEM' or 'DOMAIN\MACHINENAME$' (I don’t know which one it’s
really using). Neither of those Windows Users are also SQLServer database
users. Hence the SQLServer login fails.
Through some fairly time consuming investigation I was able to discover this
tidbit:
“When an ASP.NET application starts up, it executes all its startup code in
the context of the aspnet_wp.exe process, no matter what the settings are
with regard to security. This means that code in Application_Start, and
modules defined and configured in Web.config are executed under
aspnet_wp.exe… Once the startup code was done executing, the security context
switched to the requesting user, just like it was supposed to.”
In my web.config I have the following to define my WSE 2.0
UsernameTokenManager:
<microsoft.web.services2>
<security>
<securityTokenManager type="MyUsernameTokenManager,
MyWebService"
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd name="wsse:UsernameToken"/>
</security>
</microsoft.web.services2>
How do I get WSE to impersonate like the rest of my webservice code? Is it
impossible? Will I have to add a user to my SqlServer, switch my server to
mixed mode and store a connection string somewhere? At this point this
appears to be the only solution.
This problem does not happen when IIS and the database are on the same
server. I only noticed the problem when I moved the application to
production where our database server is on a separate machine. The problem
is easily recreated. Setup one machine with IIS and WSE. Set up another
machine with SQLServer in Integrated Security mode. Create a webservice
project, turn impersonation on and setup an anonymous user for the site in
IIS manager. Now create a UsernameTokenManager that simply tries to connect
to the database in the AuthenticateToken method using integrated security.
Impersonation will not happen.
Thanks
Hi,
In your ASP.NET app/service that is reading the password stuff out of your
database, add a user id and password attribute to the Impersonate=true"
entry. This causes calls made by the service (which call into the database
to retrieve the password) to be made in the context of the specified user.
Because these items are missing, no impersonation is happening because the
request doesn't come in with NT credentials to impersonate.
I hope this helps
Dan Rogers
Microsoft Corporation
--------------------
>Thread-Topic: ASP.Net not impersonating for WSE 2.0
>thread-index: AcTXKTO01+4i9gvBQd21Z+IvmdJzDA==
>X-WBNR-Posting-Host: 142.165.62.119
>From: "=?Utf-8?B?RnJhbmNvaXM=?=" <Francois@discussions.microsoft.com>
>References: <76F4A8B3-2347-4F3D-B643-EA07B2AEE2C1@microsoft.com>
<UPE1SWn1EHA.3820@cpmsftngxa10.phx.gbl>
>Subject: RE: ASP.Net not impersonating for WSE 2.0
>Date: Tue, 30 Nov 2004 14:09:03 -0800
[quoted text clipped - 13 lines]
>Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
>Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.aspnet.webservices:26903
>X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
>
[quoted text clipped - 4 lines]
>
>In my Web Service application I???ve set <identity impersonate="true" />
in
>the web.config. *I can successfully call my database with Integrated
>security from anywhere in my web services.* On some of my webservices I
[quoted text clipped - 8 lines]
>has a column called username and one called password. My AuthenticateToken
>method essentially returns ???Select password from users where username =
??? +
>UsernameToken.Username. This query is also run with Integrated Security.
>The big difference is that it is *not* using Impersonation like the rest of
>the code in my Web Service application. Instead of running with
>MyDomain\MyPrivelegedUser like _all_ my other web service code, it runs with
>'NT AUTHORITY\SYSTEM' or 'DOMAIN\MACHINENAME$' (I don???t know which one
it???s
>really using). Neither of those Windows Users are also SQLServer database
>users. Hence the SQLServer login fails.
>
>Through some fairly time consuming investigation I was able to discover this
>tidbit:
>???When an ASP.NET application starts up, it executes all its startup code
in
>the context of the aspnet_wp.exe process, no matter what the settings are
>with regard to security. This means that code in Application_Start, and
>modules defined and configured in Web.config are executed under
>aspnet_wp.exe??? Once the startup code was done executing, the security
context
>switched to the requesting user, just like it was supposed to.???
>
[quoted text clipped - 123 lines]
>> >
>> >Francois