Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
.NET remoting components can be hosted by IIS or by custom surrogate host processes such as Windows services.
In the first case, one can take advantage of IIS security features—specifically basic authentication, integrated authentication, and htpps—to obtain the same level of identity flow and impersonation functionalities offered to the ASP.NET Web presentation layer and ASP.NET Web services. All you need is to configure the remoting client side properly so that the .NET runtime transmits the client identity information across the wire.
In case the ASP.NET application is configured to use integrated security, all you need is to place the following line in the client remoting configuration file:
<channel ref="http" useDefaultCredentials="true" />
If the server side is configured for basic authentication, you need to write a few lines of extra code before calling the remote object:
RemotingTypes.mySAO myobj = (RemotingTypes.mySAO) [ccc]Activator.GetObject(typeof(mySAO), [ccc]"https://localhost:80/RemotingAccess/sAO.rem"); IDictionary props = ChannelServices.GetChannelSinkProperties(myobj); props["username"] = "Administrator"; props["password"] = "xyz"; //call the remote object MessageBox.Show(myobj.hello());
When hosting .NET remoting components in a custom hosting process, you are quite on your own because .NET remoting doesn't provide any sort of built-in security mechanism. Again, you have two basic options at your disposal. In the first one, you transmit (out of band using CallContext) the custom client identity or the username-password pair. In case you send a custom identity, you can just attach it to Thread.CurrentPrincipal and you are done (no Impersonation issues here).
If you transmit a username-password, you typically need to reconstruct a WindowsIdentity on the server side. To do this, call LogonUser and ImpersonateLoggedOnUser, as described above. In both cases, take all required steps to avoid identity spoofing and network sniffing. Send username-passwords and identity objects encrypted across the wire using .NET symmetric encryption libraries. This raises the challenge of protecting the shared encryption key; in this case, the recommended approach is storing it using DPAPI (Data Protection API).
The second approach consists of performing a client-server authentication using Windows authentication providers such as NTLM or Kerberos (as DCOM does). This approach is far more complicated; fortunately, Microsoft has made available a nice piece of software (in the form of a custom .NET remoting channel sink) that does exactly this (transparently both at the client and at the server side). You can download this .NET Remoting add-on here.