EDN Admin
Well-known member
<span lang="EN-US" style="font-family:Cambria I am developing an application that needs to load plug-ins into separate child app domains. Only one plug-in is loaded into one child app domain. Each plug-in requires different Windows identity and those identities
are different from the Windows identity used in default (parent) app domain. Each plug-in loads one or more of its child plug-ins.
<span lang="EN-US" style="font-family:Cambria E.g. Identity of default app domain is
AuthorityLimited (Authority is either domain name or machine name). Two plug-ins are loaded into two child app domains. The identities of the loaded plug-ins are
AuthorityPrivileged1 and AuthorityPrivileged2 . AuthorityPrivileged1 and
AuthorityPrivileged2 have all necessary access to databases Database1 and
Database2 , respectively, whereas the AuthorityLimited does not have access to any of aforementioned databases.
<span lang="EN-US" style="font-family:Cambria When creating child app domain, I call
System.AppDomain.SetThreadPrincipal method passing <span> <span style="font-family:Cambria System.Security.Principal.WindowsPrincipal
<span><span style="font-family:Cambria instance. The instance was created from
System.Security.Principal.WindowsIdentity instance created from duplicated user token (see
http://support.microsoft.com/kb/306158 http://support.microsoft.com/kb/306158 ). I have omitted the call to
WindowsIdentity.Impersonate method since I am in default app domain while creating the
WIndowsPrincipal instance.
<span><span style="font-family:Cambria I expected that setting the app domains thread principal would be sufficient for the loaded plug-ins to successfully log in to their respective databases and execute some T-SQL statements. To my surprise, the value
returned by WindowsIdentity.GetCurrent() method is used when opening a connection to database. The value returned by the method is either process identity or impersonated identity.
<span><span style="font-family:Cambria Since the process identity does not have permissions necessary to work with the databases, it is not acceptable. Therefore, impersonation must come to play. However, impersonation must take place only in child app
domains.
<span><span style="font-family:Cambria Each plug-in exposes methods used to perform loading and unloading of the plug-in. I understand that I have to perform impersonation at the start and undo the impersonation at the end of those methods.
<span><span style="font-family:Cambria However, the impersonation must be done for all threads spawned in the child app domains as well. Since each plug-in
<span lang="EN-US" style="font-family:Cambria loads one or more of its child plug-ins and each plug-in might spawn one or more threads, the impersonation would have to be performed in many places, and that looks very messy.
<span lang="EN-US" style="font-family:Cambria Is it possible to perform impersonation
only once so that affects all threads that are spawned in the child app domains?
<br/>
<span style="font-family:Cambria Please note that the application already supports running child processes under arbitrary identity. However, it must support same thing for child app domains.
<span>
View the full article
are different from the Windows identity used in default (parent) app domain. Each plug-in loads one or more of its child plug-ins.
<span lang="EN-US" style="font-family:Cambria E.g. Identity of default app domain is
AuthorityLimited (Authority is either domain name or machine name). Two plug-ins are loaded into two child app domains. The identities of the loaded plug-ins are
AuthorityPrivileged1 and AuthorityPrivileged2 . AuthorityPrivileged1 and
AuthorityPrivileged2 have all necessary access to databases Database1 and
Database2 , respectively, whereas the AuthorityLimited does not have access to any of aforementioned databases.
<span lang="EN-US" style="font-family:Cambria When creating child app domain, I call
System.AppDomain.SetThreadPrincipal method passing <span> <span style="font-family:Cambria System.Security.Principal.WindowsPrincipal
<span><span style="font-family:Cambria instance. The instance was created from
System.Security.Principal.WindowsIdentity instance created from duplicated user token (see
http://support.microsoft.com/kb/306158 http://support.microsoft.com/kb/306158 ). I have omitted the call to
WindowsIdentity.Impersonate method since I am in default app domain while creating the
WIndowsPrincipal instance.
<span><span style="font-family:Cambria I expected that setting the app domains thread principal would be sufficient for the loaded plug-ins to successfully log in to their respective databases and execute some T-SQL statements. To my surprise, the value
returned by WindowsIdentity.GetCurrent() method is used when opening a connection to database. The value returned by the method is either process identity or impersonated identity.
<span><span style="font-family:Cambria Since the process identity does not have permissions necessary to work with the databases, it is not acceptable. Therefore, impersonation must come to play. However, impersonation must take place only in child app
domains.
<span><span style="font-family:Cambria Each plug-in exposes methods used to perform loading and unloading of the plug-in. I understand that I have to perform impersonation at the start and undo the impersonation at the end of those methods.
<span><span style="font-family:Cambria However, the impersonation must be done for all threads spawned in the child app domains as well. Since each plug-in
<span lang="EN-US" style="font-family:Cambria loads one or more of its child plug-ins and each plug-in might spawn one or more threads, the impersonation would have to be performed in many places, and that looks very messy.
<span lang="EN-US" style="font-family:Cambria Is it possible to perform impersonation
only once so that affects all threads that are spawned in the child app domains?
<br/>
<span style="font-family:Cambria Please note that the application already supports running child processes under arbitrary identity. However, it must support same thing for child app domains.
<span>
View the full article