Partial Trust Environments
| Retired Content |
|---|
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
| The latest Enterprise Library information can be found at the Enterprise Library site. |
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
- Changes from Enterprise Library 2.0
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 only to the code that really requires it. 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.
Changes from Enterprise Library 2.0
To use partial trust policies, versions of Enterprise Library from 3.0 onwards differ from Enterprise Library version 2.0 in the following ways:
- Most assembly-level permission demands were removed because the .NET Framework will not allow these assemblies to run if they are only partially trusted. This is true even if the permissions are only required in a few isolated places, such as instrumentation calls that write to the event log.
- In situations where additional permissions are required for certain application block features, permission demands are implemented in code (either in Enterprise Library code or in the base .NET Framework class libraries) and are limited to the features that require these permissions.
- Where possible, if the requested permissions cannot be granted, the code will degrade gracefully instead of failing outright. For example, if the Logging Application Block is unable to call the API that provides information about the current process, this information is simply left out of the logged message.
Changes from Enterprise Library 3.x
Versions of Enterprise Library from 4.0 onwards, including this release, have the Allow Partially-Trusted Caller attribute (APTCA) on all assemblies. This means that you can call the methods of Enterprise Library and the application blocks from an application running in a partial trust environment. You can do this with the signed assemblies provided with Enterprise Library. There is no longer any requirement, as there was in version 3.x, to recompile the source code and the source code for ObjectBuilder then either use the unsigned binaries or strong-name them yourself.
However, depending on which features of the Enterprise Library you use in your application, it may still be necessary to grant your application additional permissions in addition to those provided by default with the partial-trust policy. As an example, see How To: Use Medium Trust in ASP.NET 2.0 for details about how to create a custom policy that is based on medium trust.
One particularly important requirement is that for any application block to read information from configuration files, it is necessary to grant the application ConfigurationPermission, which is not provided by default in medium trust in the custom policy definition. Alternatively, you can add the requirePermission attribute****to the relevant sections of the application's configuration file and set it to false. The following example allows the Logging Application Block to read configuration information.
<configuration>
<configSections>
<section name="loggingConfiguration"
type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings,
Microsoft.Practices.EnterpriseLibrary.Logging"
requirePermission="false"/>
</configSections>
</configuration>
You can modify the value of the RequirePermission property in the configuration tool by selecting a top-level block node in the configuration editor. This value is now saved by the tool; it is no longer overwritten as in some earlier versions.