Building Secure ASP.NET Applications phần 6 ppt

Building Secure ASP.NET Applications262 Client Proxy Formatter Sink Sink Transport Sink Channel Channel Custom Sink Object Host Process Formatter Sink Sink Transport Sink Channel Custom Sink Figure 11.1 The .NET remoting architecture The client communicates with an in-process proxy object. Credentials for authenti- cation (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 encryp- tion) 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. Remoting Sinks .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 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. Chapter 11: .NET Remoting Security 263 ● 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. Comparing Transport Channel Sinks The following table provides a comparison of the two main transport channel sinks. Table 11.1: Comparison of TcpChannel and HttpChannel Feature TCP Channel HTTP Channel Comments Authentication No Yes The HTTP channel uses the authentica- tion features provided by IIS and ASP.NET, although Passport and Forms authentica- tion is not supported. Authorization No Yes The HTTP channel supports the authori- zation features provided by IIS and ASP.NET. These include NTFS permissions, URL authorization and File authorization. Secure Yes Yes Use IPSec with the TCP channel. Use Communication SSL and/or IPSec with the HTTP channel. Custom Sinks 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 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.” Building Secure ASP.NET Applications264 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. Anatomy of a Request When Hosting in ASP.NET 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. 4 6 3 2 1 IIS (inetinfo.exe) HTTP Request (.rem/ .soap) Firewall Web Server ISAPI Mapping aspnet_isapi.dll ASP.NET (aspnet_wp.exe) App Domain System.Runtime .Remoting Object 5 Web.config Figure 11.2 Server-side processing Figure 11.2 shows the following sequence of events: 1. A .soap or .rem request is received over HTTP and is mapped to a specific virtual directory on the Web server. 2. IIS checks the .soap/.rem mapping and maps the file extension to the ASP.NET ISAPI extension, Aspnet_isapi.dll. 3. 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. Chapter 11: .NET Remoting Security 265 4. The HttpRemotingHandlerFactory handler is invoked and the remoting infra- structure 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). 5. The remoting infrastructure locates the assembly that contains the remote object and instantiates it. 6. 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 authoriza- tion. For example, by using principal permission demands and programmatic role checks. ASP.NET and the HTTP Channel 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. Building Secure ASP.NET Applications266 ● Authorization Features. Clients are authorized using standard ASP.NET authori- zation 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. More Information ● 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. .NET Remoting Gatekeepers The authorization points (or gatekeepers) available to a remote object hosted by ASP.NET are: ● IIS. With anonymous authentication turned off, IIS only permits requests from users that it can authenticate either in its domain or in a trusted domain. IIS also provides IP address and DNS filtering. ● ASP.NET ● UrlAuthorizationModule. You can configure <authorization> elements within your application’s Web.config to control which users and groups of users should have access to the application. Authorization is based on the IPrincipal object stored in HttpContext.User. ● FileAuthorizationModule. The FileAuthorizationModule is available to remote components, although this requires specific configuration, as de- scribed in “Using File Authorization” later in this chapter. Note: Impersonation is not required for File authorization to work. Chapter 11: .NET Remoting Security 267 The FileAuthorizationModule class only performs access checks against the requested file or URI (for example .rem and .soap), and not for files accessed by code within the remote object. ● Principal Permission Demands and Explicit Role Checks. In addition to the IIS and ASP.NET configurable gatekeepers, you can also use principal permission demands (declaratively or imperatively) as an additional fine-grained access control mechanism. Principal permission checks allow you to control access to classes, methods, or individual code blocks based on the identity and group membership of individual users, as defined by the IPrincipal object attached to the current thread. Note: Principal permission checks used to demand role membership are different from calling IPrincipal.IsInRole to test role membership. The former results in an exception if the caller is not a member of the specified role, while the latter simply returns a Boolean value to confirm role membership. With Windows authentication, ASP.NET automatically attaches a WindowsPrincipal object that represents the authenticated user to the current Web request (using HttpContext.User). Authentication When you use remoting in conjunction with an ASP.NET Web application client, authentication occurs within the Web application and at the remote object host. The available authentication options for the remote object host depend on the type of host. Hosting in ASP.NET When objects are hosted in ASP.NET the HTTP channel is used to communicate method calls between the client-side proxy and the server. The HTTP channel uses the HTTP protocol to authenticate the remote object proxy to the server. The following list shows the range of authentication options available when you host inside ASP.NET: ● IIS Authentication Options. Anonymous, Basic, Digest, Windows Integrated and Certificate. ● ASP.NET Authentication Options. Windows authentication or None (for custom authentication implementations). Building Secure ASP.NET Applications268 Note: Forms and Passport authentication cannot be used directly by .NET Remoting. Calls to remote objects are designed to be non-interactive. If the client of the remote object is a .NET Web application, the Web application can use Forms and Passport authentication and pass credentials explicitly to the remote object. This type of scenario is discussed further in the “Flowing the Original Caller” section later in this chapter. Hosting in a Windows Service When objects are hosted in a Windows service, the TCP channel is used to commu- nicate method calls between the client and server. This uses raw socket-based communications. Because there is no authentication provided with sockets, there is no way for the server to authenticate the client. In this scenario, the remote object must use custom authentication. Custom Authentication For simple custom authentication, the remote object can expose a Login method which accepts a user name and password. The credentials can be validated against a store, a list of roles retrieved, and a token sent back to the client to use on subse- quent requests. When the token is retrieved at the server it is used to create an IPrincipal object (with roles) which is stored in Thread.CurrentPrincipal, where it is used for authorization purposes. Other examples of custom authentication include creating a custom transport channel sink that uses an inter-process communication channel that provides authentication, such as named pipes, or creating a channel sink that performs authentication using the Windows Security Service Provider Interface (SSPI). More Information ● For information about how to host an object in a Windows service, see “How To: Host a Remote Object in a Windows Service” in the Reference section of this guide. ● For more information about sinks and sink chains, search for see the section of the .NET Framework on “Sinks and Sink Chains” in the MSDN Library. ● For more information about how to create a custom authentication solution that uses SSPI, see the 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. Note: The implementation in this article is a sample and not a product tested and sup- ported by Microsoft. Chapter 11: .NET Remoting Security 269 Authorization When objects are hosted by ASP.NET and the HTTP channel is used for communica- tion, the client can be authenticated and authorization can be controlled by the following mechanisms: ● URL authorization ● File authorization ● Principal permission demands (declarative and imperative) ● IPrincipal.IsInRole checks in code When objects are hosted in a Windows service, there is no authentication provided by the TCP channel. As a result, you must perform custom authentication and then perform authorization by creating an IPrincipal object and storing it in Thread.CurrentPrincipal. You can then annotate your remote object’s methods with declarative principal permission demand checks, like the one shown below. [PrincipalPermission(SecurityAction.Demand, Role="Manager")] void SomeMethod() { } Within your object’s method code, imperative principal permission demands and explicit role checks using IPrincipal.IsInRole can also be used. Using File Authorization You may want to use built-in Windows access control to secure the remote object as a securable Windows resource. Without File authorization (using Windows ACLs), you only have URL authorization. To use the FileAuthorizationModule to authorize access to remote object endpoints (identified with .rem or .soap URLs), you must create a physical file with the .rem or .soap extension within your application’s virtual directory. Note: The .rem and .soap extensions are used by IIS to map requests for object endpoints to the ASP.NET ISAPI extension (aspnet_isapi.dll). They do not usually exist as physical files.  To configure File authorization for .NET Remoting 1. Create a file with the same name as the objectUri (for example, RemoteMath.rem) in the root of the application’s virtual directory. Building Secure ASP.NET Applications270 2. Add the following line to the top of the file and save the file. <%@ webservice class="YourNamespace.YourClass" %> 3. Add an appropriately configured ACL to the file using Windows Explorer. Note: You can obtain the objectUri from the web.config file used to configure the remote object on the server. Look for the <wellknown> element, as shown in the following example. <wellknown mode="SingleCall" objectUri="RemoteMath.rem" type="RemotingObjects.RemoteMath, RemotingObjects, Version=1.0.000.000 Culture=neutral, PublicKeyToken=4b5ae668c251b606"/> More Information ● For more information about these authorization mechanisms, see Chapter 8, “ASP.NET Security.” ● For more information about principal permission demands, see Chapter 8, “ASP.NET Security.” Authentication and Authorization Strategies In many applications that use .NET Remoting, the remote objects are used to pro- vide business functionality within the application’s middle tier and this functional- ity is called by ASP.NET Web applications. This arrangement is shown in Figure 11.3. Web Server IIS ASP.NET Application Server Database Server IIS .NET Remoting ASP.NET SQL Server Figure 11.3 Remote objects called by an ASP.NET Web application In this scenario, the IIS and ASP.NET gatekeepers available to the Web application can be used to secure access to the client-side proxy, and the IIS and ASP.NET gatekeepers available to the ASP.NET host on the remote application server are available to secure access to the remote object. Chapter 11: .NET Remoting Security 271 There are essentially two authentication and authorization strategies for remote objects that are accessed by .NET Web applications. ● You can authenticate and authorize callers at the Web server and then flow the caller’s security context to the remote object by using impersonation. This is the impersonation/delegation model. With this approach you use an IIS authentication mechanism that allows you to delegate the caller’s security context, such as Kerberos, Basic, or Forms authenti- cation (the latter two allow the Web application to access the caller’s credentials) and explicitly flow credentials to the remote object using the remote object’s proxy. The ASP.NET configurable and programmatic gatekeepers (including URL authorization, File authorization, principal permission demands, and .NET roles) are available to authorize individual callers within the remote object. ● You can authenticate and authorize callers at the Web server and then use a trusted identity to communicate with the remote object. This is the trusted subsystem model. This model relies on the Web application to authenticate and properly authorize callers before invoking the remote object. Any requests received by the remote object from the trusted identity projected from the Web application are allowed to proceed. More Information ● For more information about the impersonation/delegation and trusted sub- system models, see “Resource Access Models” in Chapter 3, “Authentication and Authorization.” ● For more information about using the original caller model with remoting, see “Flowing the Original Caller” later in this chapter. ● For more information about using the trusted subsystem model with remoting, see “Trusted Subsystem” later in this chapter. Accessing System Resources For details about accessing system resources (for example, the event log and the registry) from a remote object hosted by ASP.NET, see “Accessing System Re- sources” in Chapter 8, “ASP.NET Security.” The approaches and restrictions dis- cussed in Chapter 8 also apply to remote objects hosted by ASP.NET. [...]... security features offered by IIS and ASP.NET Advantages If you host remote objects in IIS, you benefit from the following advantages: q Authentication, authorization, and secure communication features provided by IIS and ASP.NET are immediately available q You can use the auditing features of IIS q The ASP.NET worker process is always running 288 Building Secure ASP.NET Applications q q You have a high... UserName = "Bob" 284 Building Secure ASP.NET Applications Choosing a Host The trusted subsystem model means that the remote object host does not authenticate the original callers However, it must still authenticate (and authorize) its immediate client (the ASP.NET Web application in this scenario), to prevent unauthorized applications issuing requests to the remote object If you host within ASP.NET and use...272 Building Secure ASP.NET Applications Accessing Network Resources When you access network resources from a remote object, you need to consider the identity that is used to respond to network authentication challenges from the remote computer You have three options: q The Process Identity (this is the default) If you host within ASP.NET, the identity used to run the ASP.NET worker process... earlier in this chapter Note: IPrincipal objects do not flow across NET Remoting boundaries 2 76 Building Secure ASP.NET Applications There are two ways to flow the caller’s context: q Pass default credentials and use Kerberos authentication (and delegation) This approach requires that you impersonate within the ASP.NET Web application and configure the remote object proxy with DefaultCredentials obtained... Introducing Data Access Security Figure 12.1 on the next page shows key security issues associated with data access 294 Building Secure ASP.NET Applications 4 Windows or SQL (Authentication) Client Identity Client Application 2 (for example ASP.NET) Data Access Identity SQL Server SQL Server Secure Connection String Storage 1 3 SSL or IPSec (Privacy/Integrity) 5 Database Permissions (Authorization) Figure... model, where the original caller is checked at the IIS /ASP.NET gate, mapped to a role, and then authorized based on role membership System resources for the application are then authorized at the application or role level using service accounts, or using the application’s process identity (such as the ASPNET account) 2 96 Building Secure ASP.NET Applications Figure 12.3 shows the two models Web Server... objects: q Host in ASP.NET q Host in a Windows Service q Host in a Console Application Recommendation 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... server to use Windows Integrated authentication because this provides tighter security — credentials are not passed across the network and are not available to the application 282 Building Secure ASP.NET Applications Configure ASP.NET (Remote Object Host) Step More Information Configure ASP NET to use Windows authentication Edit Web.config in the application’s virtual directory Set the ... Step Disable Anonymous access for your Web application’s virtual root directory Enable Windows Integrated Authentication for the Web application’s virtual root More Information 278 Building Secure ASP.NET Applications Configure ASP.NET (Remote Object Host) Step More Information Configure ASP NET to use Windows authentication Edit Web.config in the application’s virtual directory Set the ... element to: Disable impersonation Edit Web.config in the application’s virtual directory Set the element to: 2 86 Building Secure ASP.NET Applications Using a Windows Service Host If you are using a Windows service host process, you must create a Windows account to run the service This security context provided by this account . side objects are designed for non-interactive use. Building Secure ASP. NET Applications2 66 ● Authorization Features. Clients are authorized using standard ASP. NET authori- zation techniques. Configurable. for the Web application’s virtual root Building Secure ASP. NET Applications2 78 Configure ASP. NET (Remote Object Host) Step More Information Configure ASP. NET to use Edit Web.config in the application’s. file extension to the ASP. NET ISAPI extension, Aspnet_isapi.dll. 3. The ISAPI extension transfers the request to an application domain inside the ASP. NET worker process (Aspnet_wp.exe). If this