Design Considerations

Before you begin to develop remote components , there are a number of issues to consider at design time. The key security considerations are:

• Do not expose remoted objects to the Internet .

• Use the HttpChannel to take advantage of ASP.NET security .

• Use the TcpChannel only in trusted server scenarios .

Do Not Expose Remoted Objects to the Internet

You should only host remoted objects on middle-tier application servers that are not directly accessible from the Internet, and that are only accessible from front-end Web applications and Web services. If you need to expose functionality provided by a remoted object to Internet clients , use a Web service to wrap the middle- tier object and expose the Web service to the Internet.

Use the HttpChannel to Take Advantage of ASP.NET Security

If security is your primary concern, use ASP.NET to host remoted objects. This allows you to take advantage of the authentication, authorization, and secure communication features provided by ASP.NET and IIS. For example, you can use Windows authentication and use SSL to provide privacy and for the integrity of requests and responses sent over the network.

Use the TcpChannel Only in Trusted Server Scenarios

If you use the TcpChannel with a custom host process for performance reasons, remember that no built-in authentication services exist.

For this reason, you should only use the TcpChannel in trusted server scenarios, where the upstream Web application or Web service authenticates and authorizes the original callers before it calls your middle-tier remoted components. To secure this scenario, use IPSec for machine-level authentication and secure communication. The IPSec policy should only permit traffic from the nominated Web server(s) to the middle-tier remote component host. This trusted server scenario is shown in Figure 13.3.

Figure 13.3: Remoting in a trusted server scenario

For more information about IPSec, see "How To: Use IPSec" in the "How To" section of this guide.

TcpChannel Considerations

If you use a custom executable host and the TcpChannel , and you cannot rely on an upstream Web application to perform client authentication and authorization, you have to develop your own authentication and authorization solutions.

As part of a custom solution you might decide to pass principal objects as method parameters or in the call context. You should only do so in a trusted environment to prevent malicious client-side code from creating an IPrincipal object with elevated roles and then sending it to your server. Your server implementation must be able to trust IPrincipal objects before using them for role-based authorization.

An alternative approach is to use the underlying services of the Security Support Provider Interface (SSPI). For more information about this approach, see MSDN article, ".NET Remoting Security Solution, Part 1: Microsoft.Samples.Security.SSPI Assembly," at http://msdn.microsoft.com/library/en-us/dndotnet/html/remsspi.asp.

To provide secure communication when you use the TcpChannel , use IPSec or a custom encryption channel sink to encrypt the request data.