|
|
The .NET Framework provides a remoting infrastructure that allows clients to communicate with objects, hosted in remote application domains and processes, or on remote computers. This chapter shows you how to implement secure .NET Remoting solutions.
Figure 11.1 on the next page shows the basic .NET Remoting architecture when a remote object is hosted within ASP.NET. An ASP.NET host, coupled with the HTTP channel for communication, is the recommended approach if security is the key concern, because it allows the remote object to utilize the underlying security services provided by ASP.NET and IIS.
For more information about the range of possible host and channel types, together with comparison information, see “Choosing a Host Process” later in this chapter.
The client communicates with an in-process proxy object. Credentials for authentication (for example, user names, passwords, certificates, and so on) can be set through the remote object proxy. The method call proceeds through a chain of sinks (you can implement your own custom sinks, for example, to perform data encryption) and onto a transport sink that is responsible for sending the data across the network. At the server side, the call passes through the same pipeline after which the call is dispatched to the object.
| Note |
The term proxy used throughout this chapter refers to the client-side, in-process proxy object through which clients communicate with the remote object. Do not confuse this with the term proxy server. |
.NET Remoting uses transport channels sinks, custom channel sinks, and formatter channel sinks when a client invokes a method call on a remote object.
Transport channel sinks pass method calls across the network between the client and the server. .NET supplies the HttpChannel and the TcpChannel classes, although the architecture is fully extensible and you can plug in your own custom implementations.
HttpChannel. This channel is designed to be used when you host a remote object in ASP.NET. This channel uses the HTTP protocol to send messages between the client and the server.
TcpChannel. This channel is designed to be used when you host a remote object in a Microsoft® Windows® operating system service or other executable. This channel uses TCP sockets to send messages between the client and the server.
Custom channels. A custom transport channel can use any underlying transport protocol to send messages between the client and server. For example, a custom channel may use named pipes or mail slots.
The following table provides a comparison of the two main transport channel sinks.
|
Feature |
TCP Channel |
HTTP Channel |
Comments |
|---|---|---|---|
|
Authentication |
No |
Yes |
The HTTP channel uses the authentication features provided by IIS and ASP.NET, although Passport and Forms authentication is not supported. |
|
Authorization |
No |
Yes |
The HTTP channel supports the authorization features provided by IIS and ASP.NET. These include NTFS permissions, URL authorization and File authorization. |
|
Secure Communication |
Yes |
Yes |
Use IPSec with the TCP channel. Use SSL and/or IPSec with the HTTP channel. |
Custom channels sinks can be used at different locations within the channel sink pipeline to modify the messages sent between the client and the server. A channel sink that provides encryption and decryption is an example of a custom channel sink.
Formatter sinks take method calls and serialize them into a stream capable of being sent across the network. .NET supplies two formatter sinks:
Binary Formatter. This uses the BinaryFormatter class to package method calls into a serialized binary stream, which is subsequently posted (using an HTTP POST) to send the data to the server. The binary formatter sets the content-type in the HTTP request to “application/octet-stream.”
The binary formatter offers superior performance in comparison to the SOAP formatter.
SOAP Formatter. This uses the SoapFormatter class to package method calls into a SOAP message. The content type is set to “text/xml” in the HTTP request and is posted to the server with an HTTP POST.
Remote object endpoints are addressed by URLs that end with the .rem or .soap file name extension, for example http://someserver/vDir/remoteobject.soap. When a request for a remote object (with the extension .rem or .soap), is received by IIS, it is mapped (within IIS) to the ASP.NET ISAPI extension (Aspnet_isapi.dll). The ISAPI extension forwards the request to an application domain within the ASP.NET worker process (Aspnet_wp.exe). The sequence of events is shown in Figure 11.2.
Figure 11.2 shows the following sequence of events:
A .soap or .rem request is received over HTTP and is mapped to a specific virtual directory on the Web server.
IIS checks the .soap/.rem mapping and maps the file extension to the ASP.NET ISAPI extension, Aspnet_isapi.dll.
The ISAPI extension transfers the request to an application domain inside the ASP.NET worker process (Aspnet_wp.exe). If this is the first request directed at this application, a new application domain is created.
The HttpRemotingHandlerFactory handler is invoked and the remoting infrastructure reads the <system.runtime.remoting> section in the Web.config that controls the server-side object configuration (for example, single-call or singleton parameters) and authorization parameters (from the <authorization> element).
The remoting infrastructure locates the assembly that contains the remote object and instantiates it.
The remoting infrastructure reads the HTTP headers and the data stream, and then invokes the method on the remote object.
| Note |
During this process, ASP.NET calls the normal sequence of event handlers. You can optionally implement one or more of these in Global.asax. For example, BeginRequest, AuthenticationRequest, AuthorizeRequest, and so on. By the time the request reaches the remote object method, the IPrincipal object that represents the authenticated user is stored in HttpContext.User (and Thread.CurrentPrincipal) and is available for authorization. For example, by using principal permission demands and programmatic role checks. |
Remoting does not have its own security model. Authentication and authorization between the client (proxy) and server (remote object) is performed by the channel and host process. You can use the following combination of hosts and channels:
A custom executable and the TCP Channel. This combination does not provide any inbuilt security features.
ASP.NET and the HTTP Channel. This combination provides authentication and authorization through the underlying ASP.NET and IIS security features.
Objects hosted within ASP.NET benefit from the underlying security features of ASP.NET and IIS. These include:
Authentication Features. Windows authentication is configured within Web.config:
<authentication mode="Windows"/>
The settings in IIS control what type of HTTP authentication is used.
Common HTTP headers are used to authenticate requests. You can supply credentials for the client by configuring the remote object proxy or you can use default credentials.
You cannot use Forms or Passport authentication because the channel does not provide a way to allow the client to access cookies, which is a requirement for both of these authentication mechanisms. Also, Forms and Passport require a redirect to a logon page that requires client interaction. Remote, server side objects are designed for non-interactive use.
Authorization Features. Clients are authorized using standard ASP.NET authorization techniques.
Configurable authorization options include:
URL authorization.
File authorization (this requires specific configuration, as described in Using File Authorization later in this chapter).
Programmatic authorization options include:
Principal permission demands (declarative and imperative).
Explicit role checks using IPrincipal.IsInRole.
Secure Communication Features. SSL (and/or IPSec) should be used to secure the transport of data between the client and server.
For more information about the authentication and authorization features provided by ASP.NET and IIS, see Chapter 8, “ASP.NET Security.”
For information about how to host an object in ASP.NET/IIS, see article Q312107, “HOW TO: Host a Remote Object in Microsoft Internet Information Services,” in the Microsoft Knowledge Base.
|
|
