 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / August 2007Subject: WSE 3.0 Running under default ASPNet user
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. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. 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 This posting is provided "AS IS" with no warranties, and confers no rights. 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 This posting is provided "AS IS" with no warranties, and confers no rights. 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 This posting is provided "AS IS" with no warranties, and confers no rights. Free MagazinesGet 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 ...
|
Reply to this Message
|
 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.