Remoting Security | MCAD/MCSD Training Guide (70-310): Developing XML Web Services and Server Components with Visual Basic(R) .NET and the .NET Framework

‚ ‚

As with Windows services and Web services, .NET Remoting applications are like any other .NET application, and can use the same imperative and declarative security techniques to protect resources. The major difference is that Remoting introduces additional "plumbing" to allow your object to be called from client applications on other computers. The objects themselves can still be protected with .NET security, just like any other objects.

With Remoting applications, the major security- related decision that you need to make is which application will host the Remoting server. You have three choices here:

Host in a console application
Host in a Windows service
Host in ASP.NET

Hosting your Remoting server in a console application is convenient , but that's about the only thing you can say in favor of this approach. You might want to use a console application, as I did in Chapter 3, ".NET Remoting," when you're developing a new Remoting server. Console applications are easier to make changes to and to debug than either Windows services or ASP.NET applications. The problem, from a security standpoint, is that console applications don't have any built-in authentication or authorization mechanisms. You can write your own custom authentication and authorization code, of course, but such schemes are notoriously difficult to actually make secure.

When you host your Remoting server in a Windows service, you're limited to using the TCP channel. This means that you must write custom code to handle authentication and authorization ‚ with the attendant danger of writing code that doesn't quite work. However, you can use the security of the underlying TCP channel to provide secure communication by making use of the IPSec standard.

With a Windows service as your Remoting host, it's easy to limit the damage that a security breach can do by choosing an appropriate account to run the service. You can also use permission refusals to make sure that the service cannot perform dangerous actions beyond the scope of its regular operations.

For secure communications ‚ for instance, when your Remoting server must make objects available to authenticated clients over the Internet ‚ your best bet is to host the server in ASP.NET. That's because hosting in ASP.NET automatically makes all the authentication, authorization, and security features of IIS available to your server just as they are available to a Web service. Clients must use the HTTP channel to communicate with the server, which is slower than the TCP channel but more secure. You can also use the logging features of IIS to track requests to the Remoting server.

When the remote object is hosted in ASP.NET, you must specify the credentials to be used for authentication via the credentials property of the channel. This code must exist in the remoting client proxy class. If you neglect to do this, credentials won't be passed to the Remoting server even if you successfully authenticate with ASP.NET. Fortunately, the code is simple because you can extract the default cached credentials that were used to authenticate in the first place:

 Dim ChannelProperties As IDictionary = _  ChannelServices.GetChannelSinkProperties( _  RemoteObjectProxy) ChannelProperties("credentials") = _  CredentialCache.DefaultCredentials

Reviewing these choices, you can see that ASP.NET is generally the best hosting solution for a Remoting server that must provide secure access for authenticated clients. For a Remoting server that has no authentication requirements, you'll probably find that hosting in a Windows service requires fewer resources and is easier to deploy.

‚ ‚

Top