 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / March 2005User authentication through web service (follow up)
My app is a .NET forms app that runs in the taskbar and periodically polls a web service. I have a client that wants the app to integrate with their Active Directory. They do not want the user to have to provide the username and password to login to the application/web service. I need to be able to send the users authenticated security token to the web service. I have looked at the UserNameToken class of the WSE 2.0 Security.Tokens namespace but it requires that you pass it the users password which is not available programatically. Is there a way to send the security context of the locally logged in user to the web service so that it can authenticate the user to the AD without requiring the user to enter their username and password into the application? --Buddy Are we talking about a web service that is 'polled' over the internet or a web service that is 'polled' over a LAN where the user is already logged in to the same domain as the web service. If it is the latter, simply change the web service to allow Windows Integrated Authentication only and, on the client, add the url of the web service to the trusted intranet sites. > My app is a .NET forms app that runs in the taskbar and periodically polls > a web service. I have a client that wants the app to integrate with their [quoted text clipped - 9 lines] > > --Buddy It is the latter (on a LAN). So, if the current client code (which I did not write) has the following in it proxy.RequestSoapContext.Security.Tokens.Add(new UsernameToken(username, password, PasswordOption.SendHashed)); proxy.RequestSoapContext.Security.Timestamp.TtlInSeconds = TimeToLive; should I remove this? Will the the client then automatically send the local security token (as a UserNameToken)? --Buddy > Are we talking about a web service that is 'polled' over the internet or a > web service that is 'polled' over a LAN where the user is already logged in [quoted text clipped - 17 lines] >> >>--Buddy I'm not sure of the finer nuts and bolts of how it actually does it but what I am talking about is: The client PC is joined to a domain The IIS server is on a member server in the same domain The current user is logged in to the domain When the web service and, of course, the hosting web site as configured for Windows Integrated Security, and the url is registered as a trusted intranet url then what happens is: Client uses url to access the web site Web site asks client for authentication information Client sends current security token to web site Web site does whatever it needs to do with this and passes request on to the web service No security related code is required in the client application. You can test this by getting a web method to write all the server variable and/or session variables out to a file and it will show that the web site/web service knows all that it needs to know authentication wise. If the web site is exposed to the internet then it is a different kettle of fish. > It is the latter (on a LAN). So, if the current client code (which I > did not write) has the following in it [quoted text clipped - 29 lines] >>> >>>--Buddy hmmmmmmmmm.... Somethings not right because I did what you suggest and it doesn't appear to be working and by "doesn't appear" I mean it isn't working. I'm creating a derived UsernameTokenManager class and overiding the AuthenticateToken method so I can authenticate the user to my database but I see no activity on my database indicating that it is trying to authenticate the user. --Buddy > I'm not sure of the finer nuts and bolts of how it actually does it but what > I am talking about is: [quoted text clipped - 55 lines] >>>> >>>>--Buddy Set a break point in the AuthenticateToken method. If the break point is not hit (I had this problem before), check: 1) You are actually sending a UT. 2) The token is already cached. In which case the Auth method is not run as it finds the UT in cache. 3) Related to 2. If client and server is in same AppDomain, I think the UT is cached when you create it on the client side so the server side "sees" it cached, hence does not run the Auth method. IIRC, you can get other strange side effects using the same appdomain. The solution is to break the app into two projects. A client and a server. Have your default project in the solution be the server project and start it. Start the client project from the right-click "Debug/Start new instance" menu command in Solution explorer. Now you have two processes/appdomains and you should hit your break point in the Auth method the first time. The next time it will have been cached and method should not run until the UT expires (see Note). Note: You can also override CacheSecurityToken() method and just return so as not cache the UT. That way, the Auth method should run each time. You can use that for testing to verify things. Normally, you would not override this method.  SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > hmmmmmmmmm.... > [quoted text clipped - 64 lines] > >>>> > >>>>--Buddy 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.