My thought was that you would use your own user/password input mechanism (or the new ASP.NET user authentication controls) to know exactly who the user is, and to determine the proper "remoting identity" (and any other "security level" things). Then you'd call Impersonate to take advantage of remoting's security mechanisms, and pass the actual username to the remoting calls so that any auditing code has it available.
In that scheme, the user/password is entered on a web form as you seem to have indicated you planned. Or do I misunderstand? At 08:17 AM 6/22/2006, Itay Zandbank wrote > > A little bit of both. We're going to have a few dozen users, and not >all of them are going to be logged on at the same time. I want to know >the user's identity for auditing as well, although this is just a happy >side-effect, I mostly want it to keep things more secure. > > How can I use Windows Authentication if my users are located in a >different network? I don't want them to enter their user/password on an >IE window. > >-----Original Message----- >From: J. Merrill [mailto:[EMAIL PROTECTED] >Sent: Wednesday, June 21, 2006 6:19 PM >Subject: Re: Programmatic Impersonation in ASP.NET 2.0 > >Are you needing to have huge numbers of different end-user identities to >determine the proper behavior of your remoting code? If the remoting >code has just a few levels of access, based on the user's "role" in your >app, you could create a few artificial Windows users that correspond to >those roles, and use Impersonate with the token from the appropriate >artificial user. > >If your remoting code needs to know specifically who the remote user is >(e.g. for audit logging) you could pass that info from your app on each >call. > >I don't know the answer to whether there's a way to avoid impersonating >on each page load, but you aren't locked out of using Windows >Authentication just because your users aren't internal. > >At 04:48 AM 6/21/2006, Itay Zandbank wrote >> In our web application, we want to impersonate the end user so that >>its identity is carried through to our middle-tier remoting services. >>We can't use Windows Authentication (the users are located on the >>internet, with no access to our domain controller), so we need to do >>the impersonation ourselves (given a username and a password, of >>course, which will be provided to the ASP.NET somehow. We won't use >>Basic Authentication). >> >> I found quite a bit of code that basically calls LogonUser to receive > >>the impersonated user's token, and then uses >>WindowsIdentity.Impersonate on that token. As far as I understand, this > >>impersonation needs to be done every time a new page is loaded. >> >> Is there a simpler way? When using Windows Authentication with >>impersonation enabled, ASP.NET impersonates the user automatically. Is >>there some sort of standard way to hook into this mechanism? Ideally - >>some place in the session we can place the token (or WindowsIdentity) >>only once, and have ASP.NET use it every time a page is loaded? >> >> And if there isn't, do we really need to call LogonUser every time a >>page is loaded? What if we cache the token in the session, and only >>call WindowsIdentity.Impersonate in the Page Loaded event? I'm worried >>here about tokens becoming stale for some reason (I'm not worried about > >>Kerberos's ticket lifetime, the defaults exceed our usage anyway). >> >> Thanks, >> Itay. J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
