Partial Trust Feature Compatibility
Windows Communication Foundation (WCF) supports a limited subset of functionality when running in a partially-trusted environment. The features supported in partial trust are designed around a specific set of scenarios as described in the Supported Deployment Scenarios topic.
WCF supports a subset of features in applications running under either of the following standard named permission sets:
Medium Trust permissions
Internet Zone permissions
Attempting to use WCF in partially-trusted applications with more restrictive permissions may result in security exceptions at runtime.
Contracts are subject to the following restrictions when running under partial trust:
The service class that implements the [ServiceContract] interface must be public and have a public constructor. If it defines [OperationContract] methods, these must be public. If it instead implements a [ServiceContract] interface, those method implementations can be explicit or private, provided that the [ServiceContract] interface is public.
When using the [ServiceKnownType] attribute, the method specified must be public.
[MessageContract] classes and their members can be public. If the [MessageContract] class is defined in the application assembly it can be internal and have internal members.
Custom bindings can be created and used in a partial trust environment, but must follow the restrictions specified in this section.
Partially-trusted applications can use WCF's transport-level security features for securing their communication. Message-level security is not supported. Configuring a binding to use message-level security results in an exception at runtime.
Bindings that use reliable messaging, transactions, or message-level security are not supported.
All serializable [DataContract] types must be public.
All serializable [DataMember] fields or properties in a [DataContract] type must be public and read/write. The serialization and deserialization of readonly fields is not supported when running WCF in a partially-trusted application.
The [Serializable]/ISerializable programming model is not supported in a partial trust environment.
Known types must be specified in code or machine-level configuration (machine.config). Known types cannot be specified in application-level configuration for security reasons.
Types that implement IObjectReference throw an exception in a partially-trusted environment.
Some collection types implement both IEnumerable<T> and IEnumerable. Examples include types that implement ICollection<T>. Such types can implement a public implementation of GetEnumerator(), and an explicit implementation of GetEnumerator(). In this case, DataContractSerializer invokes the public implementation of GetEnumerator(), and not the explicit implementation of GetEnumerator(). If none of the GetEnumerator() implementations are public and all are explicit implementations, then DataContractSerializer invokes IEnumerable.GetEnumerator().
For collection types when WCF is running in a partial trust environment, if none of the GetEnumerator() implementations are public, or none of them are explicit interface implementations, then a security exception is thrown.
Many .NET Framework collection types such as List<T>, ArrayList, Dictionary<TKey, TValue> and Hashtable are not supported by the NetDataContractSerializer in partial trust. These types have the [Serializable] attribute set, and as stated previously in the Serialization section, this attribute is not supported in partial trust. The DataContractSerializer treats collections in a special way and is thus able to get around this restriction, but the NetDataContractSerializer has no such mechanism to circumvent this restriction.
A surrogate cannot be used with the NetDataContractSerializer (using the SurrogateSelector mechanism) when running in partial trust. Note that this restriction applies to using a surrogate, not to serializing it.
Service or endpoint behaviors not marked with the AllowPartiallyTrustedCallersAttribute attribute (APTCA) that are added to the <commonBehaviors> section of a configuration file are not run when the application runs in a partial trust environment and no exception is thrown when this occurs. To enforce the running of common behaviors, you must do one of the following options:
Mark your common behavior with the AllowPartiallyTrustedCallersAttribute attribute so that it can run when deployed as a partial trust application. Note that a registry entry can be set on the computer to prevent APTCA-marked assemblies from running. .
Ensure that if the application is deployed as a fully-trusted application that users cannot modify the code-access security settings to run the application in a partial trust environment. If they can do so, the behavior does not run and no exception is thrown. To ensure this, see the levelfinal option using Caspol.exe (Code Access Security Policy Tool).
For an example of a common behavior, see How to: Lock Down Endpoints in the Enterprise.
With one exception, partially-trusted code can only load WCF configuration sections in the local app.config file. To load WCF configuration sections that reference WCF sections in machine.config or in a root web.config file requires ConfigurationPermission(Unrestricted). Without this permission, references to WCF configuration sections (behaviors, bindings) outside of the local configuration file results in an exception when the configuration is loaded.
The one exception is known-type configuration for serialization, as described in the Serialization section of this topic.
Configuration extensions are only supported when running under Full Trust.
Limited event logging is supported under partial trust. Only service activation faults and tracing/message logging failures are logged to the Event Log. The maximum number of events that can be logged by a process is 5, to avoid writing excessive messages to the Event Log.
Message logging does not work when WCF is run in a partial trust environment. If enabled under partial trust, it does not fail service activation, but no message is logged.
Restricted tracing functionality is available when running in a partial trust environment. In the <listeners> element in the configuration file, the only types that you can add are TextWriterTraceListener and the new EventSchemaTraceListener. Use of the standard XmlWriterTraceListener may result in incomplete or incorrect logs.
Supported trace sources are:
The following trace sources are not supported:
The following members of the TraceOptions enumeration should not be specified:
When using tracing in a partial trust environment, ensure that the application has sufficient permissions to store the output of the trace listener. For example, when using the TextWriterTraceListener to write trace output to a text file, ensure that the application has the necessary FileIOPermission required to successfully write to the trace file.
To avoid flooding the trace files with duplicate errors, WCF disables tracing of the resource or action after the first security failure. There is one exception trace for each failed resource access, the first time an attempt is made to access the resource or perform the action.
WCF service host does not support partial trust. If you want to use a WCF service in partial trust, do not use the WCF Service Library Project template in Visual Studio to build your service. Instead, create a new Web site in Visual Studio by choosing the WCF service Web site template, which can host the service in a Web server on which WCF partial trust is supported.
WCF is generally limited to the security considerations imposed upon it by the hosting application. For example, if WCF is hosted in a XAML Browser Application (XBAP), it is subject to XBAP limitations, as described in Windows Presentation Foundation Partial Trust Security.
The following additional features are not enabled when running indigo2 in a partial trust environment:
Windows Management Instrumentation (WMI)
Event logging is only partially enabled (see discussion in Diagnostics section).
Use of WCF features that are not supported in a partial trust environment may result in exceptions at runtime.
The best way to discover that a piece of information or action is unavailable when running in a partial trust environment is to try to access the resource or do the action inside of a try block, and then catch the failure. To avoid flooding the trace files with duplicate errors, WCF disables tracing of the resource or action after the first security failure. There is one exception trace for each failed resource access, the first time an attempt is made to access the resource or perform the action.