ASP.NET Code Access Security

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 (CAS) to help protect Web 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. For information about Code Access Security, see Code Access Security Basics.

You can configure code access security for an individual assembly by making it a strong-named assembly and by 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. Additionally, because ASP.NET supports no-compile applications, assembly-based evidence is not supported. Because ASP.NET applications include the concept of directory structures, it is much easier to configure code access security based on categories of ASP.NET applications as opposed to manually configuring the .NET Framework to work separately with each ASP.NET application on a computer.

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.

Homogenous Application Domains

By default, ASP.NET partial-trust application domains are homogeneous. Homogeneous application domains are partial-trust application domains that define a shared permission set for running code. This results in a constrained set of possible permissions for code that is running in a partial-trust application domain. It also means that the application-domain trust boundary is itself associated with a partial-trust grant set. In a homogeneous application domain that is hosted in ASP.NET, code that can be loaded is associated with one of two permission sets. Code either runs with full trust (code ffrom the GAC always runs in full trust), or code runs with the partial-trust permission set that is defined by the current trust-level setting.

After you install ASP.NET the computer contains two sets of ASP.NET partial-trust policy files. The ASP.NET 4 CAS model uses one set. The other set is used when you configure your application to use the CAS model that is provided in versions earlier than ASP.NET 4. For more information, see Code Access Security in ASP.NET 4 Applications.

The trust Configuration Element

The trust configuration element specifies a trust level. The setting can apply to the computer (machine) level. In that case, every ASP.NET application runs at that trust level. Or the setting can apply to any application root directory in the hierarchy. In that case, the trust level applies to the specific ASP.NET application.

If you want to set policy for a specific application, you can do so by editing the application Web.config file as shown in the following example:

<trust level="High" />

However, if you want to set policy at a higher level (for example, the root of a Web site that has child applications) you can disallow child applications from changing the trust level setting by using a location element as shown in the following example:

<location path="ContosoSite" allowOverride="false">
  <trust level="High" />
</location>

It is recommended that you set the level attribute of the trust configuration element to High for sites that are trusted. For sites that are not trusted, such as a Web server that hosts sites that run code from an external customer, we recommend that you set the level attribute of the trust configuration element to Medium.

The trust element provides a LegacyCasModel attribute, which is set to false by default. Setting this attribute to true configures an ASP.NET application to use most (although not all) the ASP.NET CAS behavior from versions of earlier than ASP.NET 4.

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 that are running with Full permissions can always use it. Applications that are running with lower trust levels will not be able to use resources unless you grant them explicit permissions by changing 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.

See Also

Concepts

Code Access Security in ASP.NET 4 Applications

Other Resources

ASP.NET Web Application Security