Visual Basic (Declaration)
Visual Basic (Usage)
C#
C++
J#
JScript

One of the benefits of using ASP.NET to host multiple Web sites is support in the common language runtime (CLR) for code access security to help protect server applications. Code is assigned to a security zone classification based on evidence about the code's origin, such as a strong name for an assembly or the code's URL of origin. If the CLR did not enable you to configure security for discrete applications installed on a common server, code in an ASP.NET page belonging to one application would be able to read files in another application.

Applications that run with full trust can still be constrained by NTFS file permissions, database permissions, and so on using the Windows account (the ASP.NET process identity) under which they are executing. For more information, see Configuring ASP.NET Process Identity.

In general, you can configure code access security for an individual assembly by strongly naming it and adding security policy for that assembly. However, many ASP.NET assemblies are dynamically generated during page compilation and therefore are not strongly named, so you must configure security policy for those assemblies indirectly.

For each application, ASP.NET lets you assign a configurable trust level that corresponds to a predefined set of permissions. By default, applications are assigned a trust level according to the evidence they present. For example, local applications run in the MyComputer zone with the Full permission set, and applications accessed using a Universal Naming Convention (UNC) reference run in the Intranet zone with the LocalIntranet restricted permission set. If you want to run a Web application with less than the Full permission set, you must use one of the predefined trust levels defined in ASP.NET Trust Levels and Policy Files to enforce a partial trust policy.

You can use the following configuration settings in the application's Web.config file to override the default behavior and associate an application with a given security policy:

The trust configuration element can apply to the machine level or to any application root directory in the hierarchy. If you want to set policy for an entire site, you can do so by editing the Web.config file for the root application of the site and specifying the root of the site as the path location, as in the following example:

If you are configuring trust settings at the machine or site level, you generally set the allowOverride attribute to false in the location element so that individual applications are not able to specify their own trust level. This is typical in shared server installations.

The following table lists the default supported attributes for the trust configuration element:

The following table lists permission types supported by the CLR and the default policy for each permission under different trust levels.

When a permission level is available but is not explicitly mentioned in security policy, applications running with Full permissions can always use it. Applications running with lower trust levels will not be able to use resources unless you grant them explicit permissions by altering the security policy.

As the table shows, application with High permission sets have read/write permission for files in their application directories, and Low trust applications have read-only permission for files in their application directories. Because the FileIOPermission type relies on a physical path (for example, c:\SampleAppPath), ASP.NET uses a tokenized statement in the policy files that is replaced at run time with relevant path information for the application.

The WebPermission type allows the application to connect to the origin host. In ASP.NET, you can configure this permission by providing an optional originUrl attribute on the trust section for a given application. The originUrl attribute replaces the $OriginHost$ variable in policy files, as shown in the following section from the Web_hightrust.config file:

The SocketPermission type takes a host name or IP address (which can include wildcard characters) and the WebPermission type takes a regular expression that includes the protocol (for example, http://sampleserver/.*). If you want to change the list of permitted host names, you can alter the policy files or create new ones with the desired permissions. For example, you can alter the SocketPermission section from the ASP.NET named permission set as follows to grant TCP socket connectivity to sampleserver1 and sampleserver2 on port 8080:

See Also

To make a suggestion or report a bug about Help or another feature of this product, go to the feedback site.