 |
 | 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 2005UserNameToken to Authenticate against AD
I have an ASP.NET web service that configured to runs as Ananymous, I need to authenticate/Authorize requests to this service against AD, I'm trying to achieve this by passing the UserNameToken in the soap header, but in my Web Method the Thread.CurrentPrincipal is always empty. I am under impression that the ASP.Net will automatically populate the Identity of the current user once the authentication is successful. My thought is that the authentication is happening but the Thread.CurrentPrincipal is empty, I know this fact because if i pass Invalid UserName, it throws an exception. Do I need to populate the CurrentPrincipal myself? Shouldn't the ASP.net take care of this? Please Help. Thanks Yedu. No Asp.net will not take care of this. However, If Im not mistaken, you should be able to find it in the request soap context. HTH Dilip Krishnan Yes. I have done this thru the soapContext. I was under the impression that ASP.net will take of copying the principal from the token into the current thread. thanks for the answer. > No Asp.net will not take care of this. However, If Im not mistaken, > you should be able to find it in the request soap context. > HTH > Dilip Krishnan Not sure about ASP, but this can be a problem if using the thread pool, which I think ASP does for the worker threads. The thread principal needs to be cleared before the method returns and the thread pool gets control back, otherwise it is possible another request could use the same principal object as the thread is likely to be reused. This could be a big security issue. I assume the way they handle that issue is to not make it an issue to begin with and not set the principal on the thread as the thread is really generic in respect the the thread pool. I know I could repro this issue using WSE so I am guess ASP could have the same potential issue. Not sure if a valid fix would be for the thread pool to always null this object before a new delegate is called or not. At least if it did, it would be known and expected behavior and you would not have to worry about old principle objects hanging around and wondering why some code fails at strange times - or worse, it works when it should not work. All said, I would think setting is this object on a thread pool thread should be avoided unless someone has a better answer.  SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > Yes. I have done this thru the soapContext. I was under the impression that > ASP.net will take of copying the principal from the token into the current [quoted text clipped - 6 lines] > > HTH > > Dilip Krishnan Hello William Stacey [MVP], > Not sure about ASP, but this can be a problem if using the thread > pool, which I think ASP does for the worker threads. The thread > principal needs to be cleared before the method returns and the thread > pool gets control back, otherwise it is possible another request could > use the same principal object as the thread is likely to be reused. This shouldnt be the case. This is only true if you stick some application specific context information in the thread. The principal for the thread is re-assigned everytime a request is initiated and a new thread is assigned. > This could be a big security issue. I assume the way they handle that Its not :) > issue is to not make it an issue to begin with and not set the > principal on the thread as the thread is really generic in respect the [quoted text clipped - 7 lines] > said, I would think setting is this object on a thread pool thread > should be avoided unless someone has a better answer. HTH Regards, Dilip Krishnan MCAD, MCSD.net dkrishnan at geniant dot com http://www.geniant.com > > This could be a big security issue. I assume the way they handle that > > Its not :) It "is" an issue with WSE (I saw it happen in tests). If you set the thread principle on a TP thread and don't clear it before you return the principle object stays on that thread, the TP does not clear it. Naturally, new threads started by the pool are clear. But any thread can be reused by the pool depending on usage. If ASP uses the TP, I would assume this could be an issue as well. Are you saying ASP does not use the ThreadPool? SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com That could happen in a non-http-asmx transport. It happens because the soap context is stored in the thread local storage. Now that HAS to be cleared like you said. Its different in an ASP.net model because the Httpcontext is guaranteed thread safety by the ASP.net model. Otherwise you would have a BIG problem, esply If you have a multi-user web application. Now if your web application explicitly sets the principal (or context information) in the current thread again you might have the same problem like you said. ASP.net by all means uses the thread pool, but DOES NOT store request state in the currently executing thread outside of the HttpContext (which ASP.net makes sure it creates a new one for every request). Something to think about, you'd never be able to use impersonation without compromising security if the threads current principal leaked across web requests. Dilip Krishnan
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.