Partager via

Partial Trust Environments

  • Article

Applications that use versions of the Enterprise Library prior to version 3.0 require enough permissions so that the only security level they can use is full trust. With later versions of Enterprise Library, including this version, you can run applications under partial trust. A common example is an ASP.NET application that runs in a hosted environment. Typically, these types of applications require only enough permissions to run under medium trust. Depending on the Enterprise Library features that your application uses, you may need to grant additional permissions beyond those granted by a default partial-trust policy.

This topic contains the following sections:

  • Overview of Partial Trust
  • Enterprise Library and Partial Trust
  • Enterprise Library Code Access Security and the SecurityTransparent Attribute

Overview of Partial Trust

Most common security mechanisms give rights to users based on their logon credentials (usually a password) and restrict resources such as directories and files that the users can access. However, this approach fails to address several issues: users obtain code from many sources, some of which might be unreliable; code can contain bugs or vulnerabilities that enable it to be exploited by malicious code; and code sometimes does things that the user does not know it will do.

To help protect computer systems from malicious mobile code, to allow code from unknown origins to run with protection, and to help prevent trusted code from intentionally or accidentally compromising security, the .NET Framework provides a security mechanism named code access security. Code access security allows code to be trusted to varying degrees depending on where the code originates and on other aspects of the code's identity. Code access security also enforces the varying levels of trust on code, which minimizes the amount of code that must be fully trusted in order to run. The security policy defines the level of trust and there are five default trust policies that you can assign to applications. These policies are named full, high, medium, low, and minimal. If an application has full security, code access security imposes no restrictions. Partial-trust policies impose various sets of constraints, such as restricting an application from accessing the local hard disk and from running unmanaged code.

If your application needs more permissions than those granted in a default trust level, such as medium trust, but you do not want to run in full trust, you can create a custom policy based on a default policy that grants the specific additional permissions that you need. For example, if you want to run in medium trust but you must grant your application read-only access to a directory on the user's file system, you can create a custom policy based on medium trust that also requests FileIOPermission for only that directory. Used correctly, this approach increases the functionality of your application while minimizing security risks to your users.

For more information about code access security and partial trust, see the following resources:

Enterprise Library and Partial Trust

Since its release, many customers have wanted to use the Enterprise Library in partial-trust scenarios. Most commonly, these are situations where applications run in hosted ASP.NET 2.0 environments that use medium or custom security trust policies. Partial trust is a good choice for Web sites and other environments where multiple applications are hosted on a server that supports multiple application owners.

Since version 3.0 (May 2007), Enterprise Library allows applications that have partial trust to run by isolating permissions demands so that the code can run the majority of the functions in Enterprise Library. It will fail with a security exception only when executing the individual functions that cannot operate in partial trust modes. However, depending on the application blocks, providers, and features your application uses, you may need to grant additional permissions by creating a custom security policy based on the default trust policy. For example, if you have an ASP.NET application with medium trust but you must support multiple database server types, you need to grant OleDbPermission to Web applications in addition to SqlClientPermission, which is already granted by medium trust policy.

For the specific permissions beyond those granted in medium trust needed by various features in the Enterprise Library, see Customizing the Medium Trust Policy and Limitations When Using Partial Trust.

Enterprise Library Code Access Security and the SecurityTransparent Attribute

Enterprise Library assemblies use the SecurityTransparent attribute. The SecurityTransparent attribute modifies the way permission demands are handled by the common language runtime (CLR). The SecurityTransparent attribute makes a LinkDemand into a FullDemand, thus requiring assemblies that call Enterprise Library assemblies to have the necessary permissions for the actions that EnterpriseLibrary will take. The result is to prevent your assembly from allowing partially trusted code to elevate its privileges and perform an operation that normally would not be allowed.

By using the SecurityTransparent attribute, even if the Enterprise Library assemblies are granted full trust, a method call on a type from an assembly that requires full trust for callers translates the caller check (which the Enterprise Library assembly would pass) into a stack walk, which would fail when the application itself is running in anything other than full trust. Transparent code effectively runs with either the set of permissions it was granted or the set of permissions its callers were granted, whichever is smaller. Thus, fully trusted transparent code essentially runs in the same security context of its callers, because the caller's permissions are necessarily less than or equal to FullTrust.