Programming WCF Services, 2nd Edition

Partially Trusted Services

In .NET 3.0, the only way for a service to execute in partial trust was to explicitly permit only the permissions required for it to operate, and implicitly deny all other permissions. One way of achieving that is to apply the matching permission attributes with the SecurityAction.PermitOnly flag. Consider the service in Example D-7.

Example D-7. Using permission attributes for a partially trusted service

[SecurityPermission(SecurityAction.PermitOnly,Execution = true)]
[UIPermission(SecurityAction.PermitOnly,
              Window = UIPermissionWindow.SafeTopLevelWindows)]
class MyService : IMyContract
{
   public void MyMethod(  )
   {
      Form form = new TestForm(  );
      form.ShowDialog(  );
   }
}

The service requires permission to execute (as does all managed code) and permission to display safe windows. Stacking multiple permit-only permission attributes on a class yields at runtime a single permission set that .NET uses to allow only those permissions and actively deny all others, by installing a dedicated stack-walk modifier. Even if the assembly the service resides in (as well as the app domain) grants the service full trust, all other permissions will be denied. For instance, if the service tries to perform an operation such as opening a file, that will trigger a security exception because the demand for file I/O will encounter the stack-walk modifier, which will actively deny having that permission. All the service can do is execute in its virtual sandbox and display safe windows. ...