RE: COM dll thread security issue while accessing from ASP.NET
- From: Nauman Hameed <NaumanHameed@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 18 Jan 2007 00:33:01 -0800
Hi
Well, I guess I have found a solution myself. Just posting it here for
benefit of anyone interested. Would also appreciate if any flaws in this
solution are pointed out by anyone.
I have added an event to my COM dll (lets call it 'DoImpersonate' event)
which is handled by a class in my ASP.NET web application code (lets call
this class as 'Impersonator').
As the first step of this solution, in the 'Session_Start' event handler of
the 'Global.asax' file, I save a reference to the current WindowsIdentity
object (System.Security.Principal.WindowsIdentity.GetCurrent) by assigning it
to a member variable of the 'Impersonator' class. The WindowsIdentity object
obtained in the 'Session_Start' is the windows identity of the impersonated
user account. As I mentioned in my original post, I use '<identity
impersonate="true" />' in my web.config file to force impersonation of the
IIS authenticated user account.
Following code snippet describes this step.
void Session_Start(object sender, EventArgs e)
{
// 'Impersonator' is the class which handles the 'DoImpersonate' event.
// It has a class member variable called 'Identity' which is an object of
type
// WindowsIdentity. I am assigning the current WidnowsIdentity to this
variable
// for later use.
Impersonator.Identity =
System.Security.Principal.WindowsIdentity.GetCurrent();
}
The second step of this solution is to make the COM dll internal threads
impersonate the identity of the WindowsIdentity object saved above. Whenever
I create a thread inside my COM dll, the very first thing that I do in the
thread start procedure is to raise the 'DoImpersonate' event. The event
handler in 'Impersonator' class then calls the 'Impersonate' method of the
WindowsIdentity object which I saved in the 'Session_Start' event handler. As
the 'Impersonator' event handler is running inside the COM dll thread, this
calls makes the COM dll thread impersonate the identity of the saved
WindowsIdentity object. The COM dll thread is then able to do anything which
the impersonated user account security context allows, such as
starting/stopping the windows services.
Following code snippet describes this step.
class Impersonator
{
public WindowsIdentity Identity = null;
void DoImpersonate_EventHandler()
{
WindowsIdentity checkIdentity = null;
// At this point the thread is running in the security context of the
primary
// user account, i.e. ASPNET or any other account you have configured in
// 'Machine.config'.
checkIdentity = System.Security.Principal.WindowsIdentity.GetCurrent();
try
{
if (Identity != null)
{
// Try to impersonate the saved WindowsIdentity
Identity.Impersonate();
}
}
catch(Exception ex)
{
// Handle any exceptions
}
// If the above 'Impersonate' call succeeds without any problem, the
thread
// is now running in the security context of the saved WindowsIdentity
object
// having the required permissions/privileges.
checkIdentity = System.Security.Principal.WindowsIdentity.GetCurrent();
}
}
It is important to call the 'Impersonate' method of the WindowsIdentity
object which represents the impersonated user account. If you call
'System.Security.Principal.WindowsIdentity.GetCurrent' inside the
'DoImpersonate' event handler before calling 'Impersonate', you will discover
that the windows identiy object obtained at that point is the identity object
for the local ASPNET user account (or any other user account which you have
manually configured in your 'Machine.config' file). The COM dll thread is
created in the security context of the ASPNET account and therefore has
limited permissions/privileges. By calling the 'Impersonate' method on the
saved WindowsIdentity object we make the thread impersonate the user account
which is impersonated by the ASP.NET web application, thus granting the COM
dll thread same permissions/privileges which are available to the
impersonated user account.
I have yet to test this solution thoruoghly, therefore I welcome any
comments/suggestions on that.
Regards
Nauman
.
- Prev by Date: Re: Is my SID's octet string correct? I can't find AD object with it.
- Next by Date: CheckSignature fails on ds:SignedInfo
- Previous by thread: Re: Is my SID's octet string correct? I can't find AD object with it.
- Next by thread: CheckSignature fails on ds:SignedInfo
- Index(es):
Relevant Pages
|
