MSDN Magazine - April 2008 - (Page 48)

Figure 1 Asserting Full Trust by the Proxy [assembly: AllowPartiallyTrustedCallers] [ServiceContract] public interface IMyContract { [OperationContract] void MyMethod(); } [PermissionSet(SecurityAction.Assert,Name = “FullTrust”)] public class MyContractClient : ClientBase ,IMyContract,IDisposable { public MyContractClient() {} public MyContractClient(string endpointName) : base(endpointName) {} /* More constructors */ public void MyMethod() { Channel.MyMethod(); } public new void Close() { base.Close(); } void IDisposable.Dispose() { Close(); } be it the client proxy or the service host. The allowed HTTP bindings themselves do not demand full trust, but instead demand permissions according to the context of use. On the client side, these bindings demand permission to execute (security permission with execution flag), and permission to connect to the service (Web permission with connect flag to the target URI). Beyond these demands on the client there are additional limitations on configuration. For example, the config file cannot contain any reference to any certificate store (for client-side certificate credentials) since touching the certificate store will cause WCF to demand full trust. Ideally, you would like to tap into the full power of WCF from distributed transactions to reliable calls to various security credential types to intranet (or even same-machine) application communication over TCP and inter-process communication (IPC) channels such as named pipes, and do all that without trading off CAS—that is, without resorting to full trust. Partially Trusted Clients } permissions at the assembly, class, or method level. Refusing permissions or permitting only the limited set of permissions required by the code to execute reduces the surface area for a luring attack. For more on code access security, see Chapter 12 in my book, Programming .NET Components 2nd Edition, where I devote more than 100 pages to this fundamental technology and its applications. In the .NET Framework 3.5, WCF only allows a limited set of scenarios to execute in partial trust. WCF allows only the HTTP bindings BasicHttpBinding, WSHttpBinding, and WebHttpBinding (with the exclusion of the WSDualHttpBinding) to Though the permission name be called under partial trust is specified using a string, and only with no security at all or with transport sethere is a degree of safety curity. Furthermore, in the added by the compiler in that case of the WSHttpBinding, it verifies the allowed values. aspects such as message security, reliable messaging, and transactions are disallowed. All partial trust-enabled bindings must use text encoding. The client cannot use additional WCF facilities such as diagnostics. To enable usage in a partially trusted environment, the System.ServiceModel assembly allows for partial trust callers by including the AllowPartiallyTrustedCallers attribute as part of the assembly definition: [assembly: AllowPartiallyTrustedCallers] To enable clients at any partial-trust level to use any WCF feature and binding, you need to block the demand of the bindings for full trust. The only way to do that is to have the proxy itself assert full trust. Asserting full trust can be done via the PermissionSetAttribute using the Assert flag of the SecurityAction enum and specifying the type-safe string “FullTrust” for the permission name: [PermissionSet(SecurityAction.Assert,Name = “FullTrust”)] Client-Side CAS In the first release of WCF, omitting this attribute precluded all partial-trust use. In the .NET Framework 3.5, enforcing the limited set of supported features is now the responsibility of the bindings. Each non-HTTP binding actively demands full trust of its callers, 48 msdnmagazine Foundations Though the permission name is specified using a string, there is a degree of safety added by the compiler in that it verifies the allowed values. In addition, you must prevent the client from directly accessing any method of the base class of ClientBase (which still demands full trust), so the proxy needs to hide the commonly used methods of Close and Dispose. Having the proxy class itself access methods or properties of ClientBase (such as Channel or constructors) is fine since the proxy asserts full trust. The problem is that in order to assert full trust, the proxy itself must be granted full trust, something the partially trusted client is not able to provide in the first place. Consequently, you need to factor out the proxy class to its own assembly, mark it as public, and grant that assembly full trust. You can accomplish this by using the .NET Framework 2.0 Configuration control panel applet—simply identify the proxy’s assembly using some content-based evidence such as its strong name and grant the assembly full trust. You can also install the proxy assembly in the client’s GAC. Since all assemblies coming from the GAC are granted full trust, the proxy will also gain full trust. You also need to remember to declare the AllowPartiallyTrustedCallers attribute; this will allow partially trusted callers to call the assembly. Finally, you need to add the definition of the contract used by the proxy to the proxy’s assembly (and mark the contract as public as well). This is required because WCF demands full trust of all assemblies up the call chain, and if the contract comes from a partially trusted assembly, the demand will fail. Figure 1 shows examples of these contract and proxy definitions.

Table of Contents Feed for the Digital Edition of MSDN Magazine - April 2008

MSDN Magazine - April 2008 Contents Toolbox CLR Inside Out Basic Instincts Cutting Edge Foundations Test Run Service Station Windows with C++ Going Places { End Bracket }

MSDN Magazine - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.