Wednesday, December 27, 2006

Configuring Code Access Security in SharePoint Solutions

Continuing my quest to explore all details of the new solution framework in Sharepoint v3 I stumbled on one issue of great importance: Code Access Security.

There are several options when it comes to configuring the CAS.

  1. Install the assembly in the GAC
  2. Set the trustlevel of the web application in web.config to Full
  3. Create a permission set with all permissions required by the assembly

This MSDN article describes the pros and cons of the above three options in detail. In essence the first two options are easy to implement, but may compromise security and potentially could lead to licensing issues. Microsoft's recommendation is to create permission set tailored to your application. No doubt this option is most time consuming and requires more configuration changes, nevertheless it is the most secure one.

The WSS solution framework allows the deployment of assemblies with custom CAS policy. The CAS policy definition however is different than declaring custom CAS policy for an ASP.NET web application. The snipped below shows the structure of the CAS policy definition in the WSS solution:

The first <Assembly> elements define the target location for our assemblies. The target location of the assembly is determined by the attribute DeploymentTarget="WebApplication" and in this case it is the bin directory in the root of the target web application. Since all WSS applications run by default with trust level WSS_Minimal, which does not give any permissions to our assemblies, we need to include the <CodeAccessSecurity> section in the solution manifest. This way WSS can create a new WSS_Custom trust level. This newly created trust level is based on WSS_Minimal and in addition it will include the specific permissions for our assemblies. WSS stores the definition of this trust level in "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_custom_wss_minimaltrust.config".

The assemblies included in this policy can be specified either individually by name or in a group by the public key blob.

The assemblies included in this policy can be specified either individually by name or in a group by the public key blob. To get the key blob you can use the Strong Name Tool (Sn.exe).

In the <PermissionSet> element add individual permission using the usual syntax. More about permissions and their syntax here and here . In this particular sample I included some of the commonly used permissions. After I compiled and deployed the solution I noticed that the web.config has been modified. A new trust level WSS_Custom has been created and the trust level has been set to this new level. If we look at the newly created file with our policy "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_custom_wss_minimaltrust.config" we'll notice that WSS created StrongNameMembershipCondition code group and a new <PermissionSet> element with a name made up of the solution file name and GUID.

I also tried to find out if there are ways to create UrlMembershipCondition code groups, so that I can include the target path for my assemblies and be done with it. Unfortunately it looks like this option is not available. Furthermore I was not able to create an unrestricted PermissionSet, so that I don't need to specify individual permissions. This leaves us with one option to specify all permissions required for the execution of our assemblies, which is not an easy task when working with third party assemblies and complex WSS applications. Luckily most of the time if a method fails because of missing permission the framework will throw an exception with appropriate error message.

Dovizhdane!