The Microsoft .NET Framework Remoting infrastructure has no default authentication or authorization mechanisms. However, if you host remote components with ASP.NET and use the HttpChannel for communication, you can use ASP.NET and IIS authentication and authorization services.
If performance is an issue, you might decide to use a custom host with the TcpChannel . You should only do so in trusted subsystem scenarios, where the range of possible callers is carefully controlled through out-of- band techniques such as the use of IPSec policies, which only allow communication from specified Web servers. With the TcpChannel , you must build your own authentication and authorization mechanisms. This is contrary to the principle of using tried and tested platform level security services, and requires significant development effort.
This chapter gives recommendations and guidance to help you build secure remote components. This includes components that use ASP.NET and the HttpChannel , and those that use custom executables and the TcpChannel . The typical deployment pattern assumed by this chapter is shown in Figure 13.1, where remote objects are located on a middle- tier application server and process requests from ASP.NET Web application clients , and also Windows applications deployed inside the enterprise.
In this common scenario, the remote component services requests from front-end Web applications. In this case, ASP.NET on the Web server handles the authentication and authorization of callers. In addition, middle-tier remote components are often accessed by Enterprise Windows applications.