ASP.NET Trust Levels and Policy Files
Trust levels for ASP.NET applications are defined using policy files. Trust levels are associated with policy files by using the securityPolicy configuration element, which is valid at the computer (machine) level, application level, and in an application Web.config file. You can add or remove custom trust levels by adding entries to the configuration section that specify the trust level name and the policy file to use. The default trust files are installed in the Config directory under the folder that contains the Aspnet_isapi.dll file. This same location is used for the Machine.config configuration file and for run-time security policy files.
ASP.NET Full Trust Level
The trust levels are Full, High, Medium, Low, and Minimal. The Full is equivalent to having full trust in the local computer. The ASP.NET host does not apply any additional policy to applications that are running at the full-trust level.
The following example shows the securityPolicy section of a configuration file that maps the full trust level to a policy file.
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal"/>
</securityPolicy>
</system.web>
ASP.NET Partial-Trust Levels
By default, in ASP.NET partial-trust application domains, security policy does not intersect with machine-level, user-level, or enterprise-level CAS policies. ASP.NET partial-trust application domains are homogeneous. Homogeneous application domains assign a single common permission set for running user code and simplify CAS decisions. For more information, see Homogeneous Application Domains in Code Access Security in ASP.NET 4 Applications.
In a homogeneous application domain hosted in ASP.NET, code that can be loaded is associated with one of the following permission sets:
Code runs with full trust (code from the GAC always runs in full trust).
Code runs with the partial-trust permission set that is defined by the current trustLevel setting.
Note
This behavior is different from partial-trust applications in versions of ASP.NET earlier than ASP.NET 4.
By default, the trust level for application domains for ASP.NET is full trust. The partial-trust behavior in ASP.NET takes effect when the trustLevel element's name attribute is set to a value other than Full.
The policy files that define the partial-trust permission sets for High, Medium, Low, and Minimal are all located in the CONFIG subdirectory of the .NET Framework installation directory. The following example shows the securityPolicy section of a configuration file that maps trust levels to different policy files.
<system.web>
<securityPolicy>
<trustLevel name="High" policyFile="web_hightrust.config"/>
<trustLevel name="Medium" policyFile="web_mediumtrust.config"/>
<trustLevel name="Low" policyFile="web_lowtrust.config"/>
<trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>
</securityPolicy>
</system.web>
The policy files are named by using the following pattern:
web_[trustlevelname]trust.config
For example, the partial-trust permission set for Medium trust is in the file that is named web_mediumtrust.config.
Note
The fact that the application-domain boundary is now itself partially trusted is the most common CAS change that typically requires you to modify full-trust code in order to make it work in ASP.NET 4.
If you do not want applications to be able to specify their own trust level, you can include a location element and set the allowOverride attribute to false. You might do this on a server that hosts multiple applications and that must limit the trust level of the hosted applications.
Important
In the default root Web.config file for the server, all the partial-trust related configuration sections are inside a location element whose allowOverride attribute is set to true. To lock down the computer, you change the value of the allowOverride attribute to false.
Modifying Trust-Level Files
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. You can customize how a permission set is associated with running code. For information about how to customize a permission set, see Homogeneous Application Domains in Code Access Security in ASP.NET 4 Applications.
Granting ASP.NET Full Trust to Assemblies
The ASP.NET 4 fullTrustAssemblies section enables you to explicitly establish a list of assembly identities that will always be granted full trust. The securityPolicy configuration section in the Web.config file contains a child fullTrustAssemblies configuration section. The FullTrustAssembliesSection section is a standard collection that supports add, remove, and clear operations, where you can specify one or more assembly identities that will be granted full trust at run time. The following example shows to configure ASP.NET full trust assembly in the fullTrustAssemblies configuration section.
<system.web>
<securityPolicy>
<fullTrustAssemblies>
<add assemblyName="MyCustomAssembly"
version="1.0.0.0"
publicKey="publicSigningKey"
/>
</fullTrustAssemblies>
</securityPolicy>
</system.web>
Each entry in the fullTrustAssemblies element identifies an assembly by its assembly name and assembly version, and by a 320-character string that is the hexadecimal character representation of the public half of the signing key. Notice that the assembly location is not specified in the definition. It is up to the individual hosting environment (such as ASP.NET 4) to find and load assemblies. If an assembly that is loaded matches the information that is contained in one of the add elements in fullTrustAssemblies, the assembly is granted full trust.
Configuring Partial Trust Visible Assemblies
In the .NET Framework 4, the CLR includes a variation of the AllowPartiallyTrustedCallersAttribute (APTCA) attribute that is referred to as conditional APTCA (C-APTCA). Conditional APTCA enables assemblies that are marked with the APTCA attribute to retain APTCA characteristics in only certain hosted environments. For more information about C-APTCA, see "Conditional APTCA" in Code Access Security in ASP.NET 4 Applications.
Host environments can supply to the CLR a list of conditional-APTCA assemblies whose APTCA characteristics should be honored. ASP.NET supplies a hard-coded list of all the ASP.NET assemblies to the CLR. If ASP.NET did not do this, Web applications would fail immediately when the first line of ASP.NET internal code tried to run in a partial-trust application domain. Since it is impossible for ASP.NET to know in advance all possible conditional-APTCA assemblies, ASP.NET includes a configuration section where conditional-APTCA assemblies can be added.
The securityPolicy configuration section in the Web.config file has a child configuration section named partialTrustVisibleAssemblies. This is a standard collection that supports add, remove, and clear operations, and where you can specify one or more assembly identities that should be treated as APTCA (if they are also marked for conditional APTCA).
The following example shows to configure ASP.NET a partial-trust assembly in the partialTrustVisibleAssemblies configuration section.
<system.web>
<securityPolicy>
<partialTrustVisibleAssemblies>
<add assemblyName="MyCustomAssembly"
publicKey="publicSigningKey"
/>
</partialTrustVisibleAssemblies>
</securityPolicy>
</system.web>
Each entry in the partialTrustVisibleAssemblies section identifies an assembly by assembly name. Each entry is also identified by a 320-character string that is the hexadecimal character representation of the public half of the signing key that is used on the conditional-APTCA attributed assembly. You do not have to specify a version attribute. Only the assembly name and public key token are required by the CLR.
For more information see, "Customizing the ASP.NET 4 Conditional APTCA List" in Code Access Security in ASP.NET 4 Applications.
Creating Policy Files That Have Custom Permission Sets
You can change the policy files or create new ones by using custom permission sets. For example, you can copy the contents of the Web_hightrust.config file and assign permission to make OLEDB connections by first adding the OleDbPermission class to the SecurityClasses section of the policy file, as shown in the following example:
<SecurityClass Name="OleDbPermission"
Description="System.Data.OleDb.OleDbPermission, System.Data, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" />
You can then specify the parameters for the specified OleDbPermission type, including restrictions for OLEDB connection strings. Next, you can specify which permission sets include the OleDbPermission security class. You do this by adding an IPermission element to the PermissionSet element that has the name attribute set to ASP.Net in the trust-policy file, as shown in the following example:
<PermissionSet
class="NamedPermissionSet"
version="1"
Name="ASP.Net">
<IPermission
class="OleDbPermission"
version="1"
Unrestricted="true" />
</PermissionSet>
Some permissions, such as the OleDbPermission permission, enable you to specify additional restrictions that narrow the access that is granted or denied. For example, the OleDbPermission permission enables you to grant access to make connections using the OLE DB .NET Framework data provider, but with restrictions on which OLEDB connection strings are allowed. The following example shows how to specify that only OLEDB connections to the Access database named catalog.mdb are allowed.
<IPermission class="OleDbPermission" version="1">
<add ConnectionString=
"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=E:\access_data\catalog.mdb""
KeyRestrictions=""data source=;user id=;password=;"
KeyRestrictionBehavior="AllowOnly"/>
</IPermission>
You can save your updated trust-policy file and replace it with the current Web_hightrust.config file. Or you can create a new trust-policy file and specify it as the policy file for the High trust level, or create a new trust level as shown in the following example:
<trustLevel name="HighCustom"
policyFile="web_highcustom.config"/>
Using this trust level definition, you can set the partial-trust policy for an ASP.NET application to use HighCustom as shown in the following example:
<trust level="HighCustom" />
To preserve the default settings, ASP.NET includes two copies of each file that contains trust-level settings. One copy is named with the file name extension .config. The .config file contains the settings for each trust level that is used by the system. The second copy is named with the file name extension .config.default and contains the default settings for the related trust level. If the current trust-level settings have been modified and you want to restore the default settings, you can replace the contents of the .config file with the contents of the .config.default file.
Using ASP.NET 2.0 CAS Behavior
You can configure ASP.NET 4 applications to use ASP.NET 2.0 CAS behavior.
In ASP.NET 4, the trust element 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. For information about using ASP.NET CAS behavior in versions earlier than ASP.NET 4, see Homogeneous Application Domains.
In the .NET Framework 4.0, regardless of the CAS model that is in effect for an ASP.NET application, partial-trust code is not allowed to perform security asserts. For more information, see "Configuring ASP.NET 4 Applications to Use the ASP.NET 2.0 CAS Model" in Code Access Security in ASP.NET 4 Applications.
See Also
Concepts
ASP.NET Security Policy Mechanics
Code Access Security in ASP.NET 4 Applications