Authorization | Improving Web Application Security: Threats and Countermeasures

Within the context of .NET Framework remoting, you can apply authorization to restrict the ability of computers and users to access functionality exposed by your remote objects. Use the following guidelines to ensure that you have an effective authorization approach:

Use IPSec for machine level access control .
Enable file authorization for user access control .
Authorize users with principal-based role checks .
Consider limiting remote access .

Use IPSec for Machine Level Access Control

You can define an IPSec policy to ensure that only a nominated Web server or cluster of servers can connect to the application server that hosts your remote objects. This significantly reduces the attack surface area.

Enable File Authorization for User Access Control

If your remote object is hosted by ASP.NET and uses Windows authentication, you can configure Windows access control lists (ACLs) on the remoting endpoints to authorize callers . ACLs are evaluated on a per-request basis by the ASP.NET FileAuthorizationModule . Under normal circumstances, a physical file representing your remoting endpoints to which your clients connect does not exist. The request for a file with a .rem or .soap extension is sufficient for IIS to be able to route the request based on application mappings defined in the IIS Metabase, to the remoting infrastructure in the appropriate ASP.NET application.

Task To configure the ASP.NET FileAuthorizationModule for .NET Framework remoting

Create a file with the same name as the value specified in the objectUri property in Web.config, for example, RemoteMath.rem, in the root of the application's virtual directory.

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"/> 
```
Add the following line to the top of the file, and then save the file.
```
 <%@ webservice class="YourNamespace.YourClass" ... %> 
```
Add an appropriately configured ACL to the file using Windows Explorer to determine which users or user groups can and cannot access the object.

Authorize Users with Principal-Based Role Checks

The FileAuthorizationModule approach described above allows you to control who can and cannot access the remote object. For finer grained authorization that can be applied at the method level, you can perform authorization checks using the IPrincipal object attached to the current request.

If your remote object is hosed by ASP.NET and you use Windows authentication, an IPrincipal object based on the authenticated caller's Windows identity is automatically created and attached to Thread.CurrentPrinicipal .

If you use a custom host, create an IPrincipal object to represent the authenticated user. The mechanics depend on your authentication approach. For example if you use a named pipe transport, you can impersonate the caller to obtain their identity and construct an IPrincipal object.

With the IPrincipal object in place you can perform authorization using principal permission demands both declaratively and imperatively and you can call IPrincipal.IsInRole .

Consider Limiting Remote Access

In some scenarios, where you use remoting for inter process or cross application domain communication on a single computer, you can set rejectRemoteRequests to true to ensure that your object cannot be accessed from remote computers as shown below.

 <channel ref="http server" rejectRemoteRequests="true" />