Cook Computing

.NET Remoting Architectural Assessment

May 23, 2003 Written by Charles Cook

Sam Gentile points to the MSDN article .NET Remoting Architectural Assessment by Pat Martin. This is well worth reading if you're thinking of using .NET Remoting in your product or application.

I found the section on authentication particularly interesting in light of my recent post which moaned about the lack of built-in security functionality in Remoting:

...To start with, you need to build your own authentication and authorization mechanisms, should you require them. The article .NET Remoting Security Solution, Part 1: Microsoft.Samples.Security.SSPI Assembly provides a very full and detailed description of a security solution for .NET Remoting that " ... implements a managed wrapper around SSPI, providing the core functionality needed to authenticate a client and server as well as sign and encrypt messages sent between the two." This is definitely a great asset and provides a "façade" for adding this functionality in a useful way. The problem is that it is not a supported product but an "informal" attempt to supply missing functionality. Also, it's a little intimidating for a developer, as the solution relies on the extensible nature of formatters and channels. All this needs to be hidden and the functionality surfaced by just adding an entry to the Remoting configuration, which depicts, for example, the use of Windows NT Challenge/Response (NTLM). It is likely, however, that such security mechanisms will be incorporated into a future version of .NET Remoting.

Another issue with Remoting is performance, again something I've discussed here. Using Named Pipes as the channel transport provides better performance than TCP so it is good to read:

So, if you need Named Pipes, Remoting offers a solution. Once again, however (as is the case with the SSPI NTLM authentication solution), this solution is currently unsupported by Microsoft. It is likely that Microsoft may address this requirement at some future date.