| 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: Console applications are easier to make changes to and to debug than either Windows services or ASP.NET applications. However, 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 of 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 the remote object in the first place: IDictionary cp = ChannelServices.GetChannelSinkProperties (RemoteObjectProxy); cp["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. | 
