|
|
Objects that are to be accessed remotely must run in a host executable. The host listens for incoming requests and dispatches calls to objects. The type of host selected influences the message transport mechanism called a channel. The type of channel that you select influences the authentication, authorization, secure communication, and performance characteristics of your solution.
The HTTP channel provides better security options, but the TCP channel provides superior performance.
You have the following main options for hosting remote objects:
Host in ASP.NET
Host in a Windows Service
Host in a Console Application
To take advantage of the security infrastructure provided by ASP.NET and IIS, it is recommended from a security standpoint to host remote objects in ASP.NET. This requires clients to communicate with the remote objects over the HTTP channel. ASP.NET and IIS authentication, authorization, and secure communication features are available to remote objects that are hosted in ASP.NET.
If performance (and not security) is the primary concern, consider hosting remote objects in Windows services.
When you host a remote object in ASP.NET:
The object is accessed using the HTTP protocol.
It has an endpoint that is accessible by a URL.
It exists in an application domain inside the Aspnet_wp.exe worker process.
It inherits the security features offered by IIS and ASP.NET.
If you host remote objects in IIS, you benefit from the following advantages:
Authentication, authorization, and secure communication features provided by IIS and ASP.NET are immediately available.
You can use the auditing features of IIS.
You have a high degree of control over the hosting executable through the <processModel> element in Machine.config. You can control thread management, fault tolerance, memory management, and so on.
You can create a Web services façade layer in front of the remote object.
If you use ASP.NET to host remote objects, you should be aware of the following disadvantages:
It requires the use of the HTTP channel which is slower than the TCP channel.
User profiles are not loaded by ASP.NET. Various encryption techniques (including DPAPI) may require user profiles.
If the object is being accessed from code running in an ASP.NET Web application, you may have to use Basic authentication.
When you host a remote object in a Windows service, the remote object lives in an application domain contained within the service process. You cannot use the HTTP channel and must use the TCP channel. The TCP channel supports the following security features:
Authentication Features
You must provide a custom authentication solution. Options include:
Using the underlying authentication services of the SSPI. You can create a channel sink that uses the Windows SSPI credential and context management APIs to authenticate the caller and optionally impersonate the caller. The channel-sink sits on top of the TCP channel. The SSPI in conjunction with the TCP channel allows the client and server to exchange authentication information. After authentication the client and server can send messages ensuring confidentiality and integrity.
Using an underlying transport that supports authentication, for example, named pipes. The named pipe channel uses named pipes as the transport mechanism. This provides authentication of the caller and also introduces Windows ACL-based security on the pipe and also impersonation of the caller.
Authorization Features
Authorization is possible only if you implement a custom authentication solution.
If you are able to impersonate the user (for example, by using an underlying named pipe transport), you can use WindowsPrincipal.IsInRole.
If you are able to create an IPrincipal object to represent the authenticated client, you can use .NET roles (through principal permission demands and explicit role checking using IPrincipal.IsInRole)
Secure Communication Features
You have two options:
Use IPSec to secure the transport of data between the client and server.
Create a custom channel sink that performs asymmetric encryption. This option is discussed later in this chapter.
If you host remote objects in Windows services, you benefit from the following advantages:
High degree of activation control over the host process
Inherits the benefits of Windows service architecture
No need to introduce IIS on your application’s middle tier
User profiles are automatically loaded
Performance is good as clients communicate over the TCP channel using binary encoded data
If you use a Windows service to host remote objects, you should be aware of the following disadvantages:
You must provide custom authentication and authorization solutions.
You must provide secure communication solutions.
You must provide auditing solutions.
When you host a remote object in a console application, the remote object lives in an application domain contained within the console application process. You cannot use the HTTP channel and must use the TCP channel.
This approach is not recommended for production solutions.
There are very few advantages to this approach, although it does mean that IIS is not required on the middle tier. However, this approach is only recommended for development and testing and not for production environments.
If you host remote objects in a custom executable, you should be aware of the following disadvantages:
The host must be manually started and runs under the interactive logon session (which is not recommended).
There is no fault tolerance.
You must provide custom authentication and authorization.
There is no auditing capability.
|
|