แก้ไข

แชร์ผ่าน

Partial trust best practices

  • บทความ

This article describes best practices when running Windows Communication Foundation (WCF) in a partial trust environment.

Serialization

Apply these practices when using the DataContractSerializer in a partially trusted application.

All serializable types must be explicitly marked with the [DataContract] attribute. The following techniques aren't supported in a partial trust environment:

Using DataContractSerializer

  • All types marked with the [DataContract] attribute must be public. Non-public types can't be serialized in a partial trust environment.

  • All [DataContract] members in a serializable [DataContract] type must be public. A type with a non-public [DataMember] can't be serialized in a partial trust environment.

  • Methods that handle serialization events (such as OnSerializing, OnSerialized, OnDeserializing, and OnDeserialized) must be declared as public. However, both explicit and implicit implementations of OnDeserialization(Object) are supported.

  • [DataContract] types implemented in assemblies marked with the AllowPartiallyTrustedCallersAttribute must not perform security-related actions in the type constructor, as the DataContractSerializer does not call the constructor of the newly instantiated object during deserialization. Specifically, the following common security techniques must be avoided for [DataContract] types:

  • Attempting to restrict partial trust access by making the type's constructor internal or private.

  • Restricting access to the type by adding a [LinkDemand] to the type's constructor.

  • Assuming that because the object has been successfully instantiated, any validation checks enforced by the constructor have passed successfully.

Using IXmlSerializable

The following best practices apply for types that implement IXmlSerializable and are serialized using the DataContractSerializer:

  • The GetSchema static method implementations must be public.

  • The instance methods that implement the IXmlSerializable interface must be public.

Using WCF from Fully Trusted Platform Code that Allows Calls from Partially Trusted Callers

The WCF partial trust security model assumes that any caller of a WCF public method or property is running in the code access security (CAS) context of the hosting application. WCF also assumes that only one application security context exists for each AppDomain, and that this context is established at AppDomain creation time by a trusted host (for example, by a call to CreateDomain or by the ASP.NET Application Manager).

Note

Code Access Security (CAS) has been deprecated across all versions of .NET Framework and .NET. Recent versions of .NET do not honor CAS annotations and produce errors if CAS-related APIs are used. Developers should seek alternative means of accomplishing security tasks.

This security model applies to user-written applications that can't assert additional CAS permissions, such as user code running in a Medium Trust ASP.NET application. However, fully trusted platform code (for example, a third-party assembly that is installed in the global assembly cache and accepts calls from partially trusted code) must take explicit care when calling into WCF on behalf of a partially trusted application to avoid introducing application-level security vulnerabilities.

Full-trust code should avoid altering the CAS permission set of the current thread (by calling Assert, PermitOnly, or Deny) prior to calling WCF APIs on behalf of partially trusted code. Asserting, denying, or otherwise creating a thread-specific permission context that is independent of the application-level security context can result in unexpected behavior. Depending on the application, this behavior may result in application-level security vulnerabilities.

Code that calls into WCF using a thread-specific permission context must be prepared to handle the following situations that may arise:

  • The thread-specific security context may not be maintained for the duration of the operation, which results in potential security exceptions.

  • Internal WCF code and any user-provided callbacks may run in a different security context than the one under which the call was originally initiated. These contexts include:

    • The application permission context.

    • Any thread-specific permission context previously created by other user threads used to call into WCF during the lifetime of the currently running AppDomain.

WCF guarantees that partially trusted code can't obtain full-trust permissions unless such permissions are asserted by a fully trusted component prior to calling into WCF public APIs. However, it doesn't guarantee that the effects of asserting full trust are isolated to a particular thread, operation, or user action.

As a best practice, avoid creating thread-specific permission context by calling Assert, PermitOnly, or Deny. Instead, grant or deny the privilege to the application itself, so that no Assert, Deny, or PermitOnly is required.

See also