ASP.NET Security Policy Mechanics

ASP.NET uses the code access security (CAS) mechanism that is provided in the .NET Framework to enforce constraints on how code is executed. This topic describes the mechanics of how ASP.NET applications use CAS policy. The topic also contains information about how ASP.NET 4 uses the CAS policy model that is provided in ASP.NET versions earlier than version 4.

In ASP.NET, when applications are running in the default CAS mode, all permissions are provided exclusively by the ASP.NET permission files. By default, security policy does not intersect with any other permission level (machine-level, user-level, or enterprise-level CAS policies.)

When you use CAS to enforce constraints on how code should be executed in your ASP.NET application, you must consider the fact that ASP.NET 4 partial-trust application domains are homogeneous. In homogenous application domains, two sets of ASP.NET partial-trust policy files are installed. You must also consider the fact that .NET Framework 4 includes conditional APTCA (C-APTCA), a variation of the AllowPartiallyTrustedCallersAttribute attribute (APTCA). For more information, see Overview of the ASP.NET 4 Code Access Security Model. Although ASP.NET homogeneous application domains constrain code to either full trust or to the named ASP.NET partial-trust permission set, you can influence how a permission set is associated with an assembly. For more information, see "Customizing Permission Set Assignment" in Code Access Security in ASP.NET 4 Applications.

The information in this section is only relevant for ASP.NET 4 applications that are running with the CAS model that is provided in ASP.NET versions earlier than version 4 (legacy CAS mode). If your application is not running in CAS legacy mode, this information is probably not of interest to you. For information about how CAS works in ASP.NET 4 and on how CAS has changed since earlier versions, see Code Access Security in ASP.NET 4 Applications.

It is possible to configure ASP.NET 4 applications to use ASP.NET 2.0 CAS behaviors. In ASP.NET, the trust element in the Web.config file provides the 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 earlier than ASP.NET 4.

The application domain policy for trust levels consists of a policy level (for example, an instance of the System.Security.Policy.PolicyLevel class) that is loaded and applied to the application domain as the application domain policy. The policy tree itself is the same for High, Medium, Low, and Minimal trust levels, except for the set of granted permissions in the ASP.NET permission set. (No policy is applied for Full.)

After computing the application domain policy for a given application (full-trust applications are exempt from this step), the policy is applied to the application domain. Application domain policy intersects with the other policy levels (Enterprise, Machine, and User) so that it can only further restrict the existing policy, not expand it.

To see how application domain policy is used to restrict granted permissions, consider the fictitious permission sets and policy levels shown in the following table.






{A, B, C, D}



{A, B, C}



{A, B, C}

Application Domain


{A, B}

The simplified application permission (ignoring permission requests) of these policy sets would be the intersection of the permissions granted at the various levels. Therefore, the intersection of P1, P2, P3, and P4 is {A, B}.

You can edit policy files by hand or you can use the Code Access Security Policy tool to administer security policy for the enterprise, machine, or user levels. For more information about using these tools, see Administering Security Policy.