RE: ASP.Net not impersonating for WSE 2.0

From: Francois (Francois_at_discussions.microsoft.com)
Date: 11/30/04 

Date: Tue, 30 Nov 2004 14:09:03 -0800

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

"Dan Rogers" wrote:

> Hi Francios,
>
> I think that I understand what you are doing, and have an idea about what
> you may be expecting to happen.
>
> When using username tokens in WSE, this is not an integrated security
> strategy. The role the SQL server plays is to allow you (the application)
> to verify that the calling user is aware of their credentials and has
> provided proper credentials with the call. As such, the applicaiton should
> not expect ASP.NET to impersonate the calling user - since this SOAP based
> authentication approach has nothing to do with windows based domain logins.
> Using user name tokens delegates all responsibility for auth to the
> application writer, and thus is not integrated into windows security at all.
>
> Setting up a database that contains credentials is similar to any
> application level database, from a coding perspective. As such, integrated
> security is the rececommended way to go. But running IIS as the system
> account is not recommended, and is resulting in your issues with identity
> at the database level. Consider putting IIS back to it's normal settings,
> and add the impersonation user / password information to the web.config
> file. Doing this allows you to use IIS in it's low security mode, and have
> your web service application calls to the database be made under an
> elevated privelege.
>
> Once you have determined that the user knows their credentials, you can
> then make your code do the right thing as far as determining the authority
> to make a call, etc. Since user tokens involve a degree of "roll your own
> applicaiton security", a number of application specific strategies are
> appropriate after this point.
>
> I hope this helps
>
> Dan Rogers
> Microsoft Corporation
>
>
> --------------------
> >Thread-Topic: ASP.Net not impersonating for WSE 2.0
> >thread-index: AcTWac/wHCNlV2KuSdyC5uLLqp7waQ==
> >X-WBNR-Posting-Host: 142.165.62.119
> >From: "=?Utf-8?B?RnJhbmNvaXM=?=" <Francois@discussions.microsoft.com>
> >Subject: ASP.Net not impersonating for WSE 2.0
> >Date: Mon, 29 Nov 2004 15:19:02 -0800
> >Lines: 37
> >Message-ID: <76F4A8B3-2347-4F3D-B643-EA07B2AEE2C1@microsoft.com>
> >MIME-Version: 1.0
> >Content-Type: text/plain;
> > charset="Utf-8"
> >Content-Transfer-Encoding: 7bit
> >X-Newsreader: Microsoft CDO for Windows 2000
> >Content-Class: urn:content-classes:message
> >Importance: normal
> >Priority: normal
> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
> >NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
> >Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
> >Xref: cpmsftngxa10.phx.gbl
> microsoft.public.dotnet.framework.aspnet.webservices:26880
> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
> >
> >I have several web services that use WSE to authenticate calling users.
> >I use a UsernameToken that validates the sent username and password
> >against our SqlServer database. The SqlServer database is on a
> >different machine than the website. For all of my database access I use
> >Windows Integrated Security. As such, I've had to change the ASP.Net
> >process model to system in the machine.config and set <identity
> >impersonate="true" /> in the web.config for the web service project.
> >For all regular db access throughout the web services the impersonation
> >works and the code can connect to the database with the user we
> >specified as the anonymous user for the website.
> >
> >However, when the password validation code for the AuthenticateToken
> >method in my custom UsernameTokenManager object runs
> >WindowsIdentity.GetCurrent().Name returns 'NT AUTHORITY\SYSTEM' and the
> >database says "Login failed for user 'DOMAIN\MACHINENAME$'"
> >
> >This means that either the code in AuthenticateToken is ran using the
> >builtin machine user, or because the class was constructed before
> >aspnet_wp.exe switched users according to the <identity
> >impersonate="true" /> tag in the web.config.
> >
> >As I see it, there are only a couple of options to fix this problem:
> >1) Add the machine user to the database (is this even possible?)
> >2) Change my db to mixed mode authentication (against MS's best
> >practises) and store the connection string somewhere
> >
> >Are there any other options? What have other people done in this
> >situation? What is my best solution? I find it hard to believe that
> >I'm the only person using WSE to authenticate against SqlServer with
> >integrated security, yet I've never seen any documentation on the
> >subject nor discussion about it on the newsgroups.
> >
> >I'm using Windows 2000/IIS 5.0/SQL Server 2000/.NET Framework 1.1 SP2
> >
> >TIA,
> >
> >Francois
> >
>
>

Relevant Pages