- Identity Flow
- Impersonation
- Trusted and Delegation Security Models
- Impersonation on ASP.NET
- Impersonation on.NET Remoting
- Impersonation On DCOM/COM+ (.NET Serviced Components)
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The DCOM protocol requires the client to identify itself to the server when connecting. COM+ role-based security uses the remote client identity to protect access to server components at the class, interface, and method level. Additionally, the client identity is available inside the server code using the SecurityCallContext.CurrentCall static method. However, by default DCOM doesn't turn impersonation on, nor does COM+. This means that the remote identity is used for "check at the gate," but the application code runs using the server process identity. Unfortunately, there is no ImpersonateClient method exposed by the Enterprise Services API, nor does it provide a way to get a reference to the WindowsIdentity object of the remote caller.
To turn impersonation on, you need to resort to P/Invoke to call the native DCOM API. The CoImpersonateClient is the method that turns impersonation on; when you are done, you can switch back the thread to its original identity calling CoRevertToSelf.
[DllImport("ole32.dll")]
static extern int CoImpersonateClient () ;
[DllImport("ole32.dll")]
static extern int CoRevertToSelf () ;
public string x(){
int i = CoImpersonateClient ();
if (i==0) {
//this returns the caller identity
string l_identity = Thread.CurrentPrincipal.Identity.Name ;
CoRevertToSelf();
return l_identity ;
}
else
throw new Exception ("CoImpersonateClient returned " + i.ToString ());
}
Know that CoImpersonateClient requires the client to set its DCOM impersonation level to impersonate or delegate (or else the call to CoImpersonateClient will fail). This happens for security reasons: The server can't work on the client's behalf if the client hasn't explicitly granted this permission to the downstream server.