dotnet web services enhancements: Grrr..bad day! Sorry about the re-repost; it seems there's more than one
place to configure an alias.

Hi,

I'm having a problem with a web service; specifically a custom
UsernameTokenManager which needs to access a remote database. The web
service is set up in IIS to use anonymous access with a UserID and Password
provided, and the web.config file is set up to impersonate and use windows
authentication; the problem comes when the request is sent to the service.

The web service needs to access a database on a remote server, and needs to
use the UserID and Password held in the IIS config; the problem is during
testing I'm noticing that during my authentication phase (my custom
UsernameTokenManager class) the database access is done via the ASPNET
user - once this has been authenticated then the rest of the application
uses the correct UserID and Password for data access. I'm (guessing) that
this would be using the NetworkService account on Server 2003.

The production SQL Server database will not accept the ASPNET or
NetworkService accounts, access must be done through the UserID and Password
provided in IIS.

I'm pretty much pulling my hair out now trying to work out how/why is the
UsernameTokenManager class is running under the default account; how can I
change this to run under the specified account settings for the rest of the
application?

Cheers,
Dave

Hi Dave,

Seems you used to suffer some problem on MSDN account setting, anyway,
you've got the managed alias configured correctly now, welcome back:)

From your description, you're encountering some problem of the WSE
usernameTokenmanager's security context when accessing a remote SQL
database. You found your imperosonated anonymous account is not used when
accessing the remote server(but used the worker process account), correct?

Though I haven't ever impersonate anonymous account in webservice and WSE,
I think the behavior here could be caused by two possible things:

1. the ASP.NET webservice pipeline haven't perform the impersonate at the
point WSE call the token manager(WSE is injected at SOAP extension stage)

2. the WSE runtime has manually call Reverttoself to change security
context back to the process identity.

I think #1 is more possible here. For the problem here, a possible
workaround is manually put code in the Custom usernameTokenmanager to
perform the impersonation. To programmatically impersonate, you need clear
text username/password credentials, here is a msdn article about
programamatic impersonate:

#How To: Use Impersonation and Delegation in ASP.NET 2.0
http://msdn2.microsoft.com/en-us/library/ms998351.aspx


Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================

Hi Dave,

How are you doing? Have you got any progress on this or does the suggestion
in previous reply helps you a little? If there is still anything we can
help, please don't hesitate to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Hi Steven,

Thanks for your response; sorry I haven't got back to you sooner - got a bit
tied up in an implementation elsewhere! I haven't yet had time to have more
than a cursory read through the entire MSDN article you pointed out, but
from what I've read I'm thinking that I may still have a problem.

Your reading of the situation was spot on, and I believe that the WebService
is behaving as you stated in point 1. My intermediate solution was to set
the authentication mode to windows and impersonate the user, storing the
username and password in the web.Config file (as I think it mentions in the
How To document); this was then encrypted. The UsernameToken class then uses
this username and password to authenticate (as does the rest of the
application).

I should mention at this point that I'm testing on WinXP, but the behaviour
is the same on Win2K3; I noticed the article has a section specifically on
Windows Server 2003, so I'll concentrate on that over the next couple of
days.

I'm probably missing something really basic here (as is usually the way!),
as I can't understand why the UsernameToken class, compiled and included as
part of the dll hosted in the IIS session with the IIS Authentication set to
anonymous and the username and password provided, is deciding to revert to
the default ASPNet/Network Service user.

As you mentioned as your second point, the other option is that the WSE
runtime has manually reverted, although I can't see why it would do it for
one setting and not the other!

I'm not too keen on having the web.config file holding the Username and
Password, even if it is encrypted; ideally we'd be using the IIS Anonymous
access username and password.

I'll post back once I've had a time to go through the article in more detail
(hopefully the next couple of days!); my last remaining hope is configuring
an application pool in IIS6 on Server 2003 to use a specific user ID will
force all applications under it to use the same ID!

If you need any more information or have any other ideas, please let me
know!!!

As I've said, I'm probably missing something totally basic - I'll post back
once I've managed to get a Windows Server 2003 machine to test on.

Thanks for your help!

Cheers,
Dave

Thanks for your followup Dave,

I'm sorry to hear that the problem still remains. As for the following
things you mentioned:

===============
My intermediate solution was to set
the authentication mode to windows and impersonate the user, storing the
username and password in the web.Config file (as I think it mentions in the
How To document); this was then encrypted. The UsernameToken class then
uses
this username and password to authenticate (as does the rest of the
application).
===============

do you mean you use the following like configuration to impersonate the
ASP.NET appliation running under your specific account?

<identity impersonate="true" userName="domain\username"
password="password..." />

If so, I'm afraid this won't work either (just like you try impersonating
the anonymous account configured in IIS), the impersonation of ASP.NET
always take place in the fixed stage during ASP.NET webservice(or web
application)'s sever-side processing pipeline, at that time, the
usernameTokenManager has already done the authentication(not be able to
utilize the impersonated security context).

Have you tried using the code to programmatically do the impersonate and
use those code in your custom UsernameTokenManager's implementeation code?

I mean you can add programmatic impersonate code in your custom token
authenticator's code(where you connect to database to query user info);

http://msdn2.microsoft.com/en-us/library/ms730079.aspx

e.g.

=====in your custom token's impelementation========

public bool authenticate_method(username , password)
{
//begin impersonate

connect to remote database and verify the user account here

//revert back
}


Anyway, please don't hesitate to post here if you have any questions or
anything unclear on this.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Hi Dave,

How are you going on this issue? Does my last reply still help some?

As always, if you need any further help from us, please feel free to post
in the newsgroup.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead