Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / December 2004

Tip: Looking for answers? Try searching our database.

ASP.Net not impersonating for WSE 2.0

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Francois - 29 Nov 2004 23:19 GMT
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
Dan Rogers - 30 Nov 2004 00:43 GMT
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==
[quoted text clipped - 17 lines]
>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
>
[quoted text clipped - 35 lines]
>
>Francois
Francois - 30 Nov 2004 22:09 GMT
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 Francios,
>
[quoted text clipped - 93 lines]
> >
> >Francois
Dan Rogers - 01 Dec 2004 00:33 GMT
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

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.