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.


Friday, December 01, 2006

SharePoint solution manifests inside and out

One of the major improvements in WSS 3 is the new solution framework, which allows the deployment of Web Parts, Features, assemblies and other files to SharePoint site or farm. The process of deploying a WSS solution has several stages: (1) Creating the solution contents; (2) Compiling the WSP (CAB) file; (3) Adding the solution to the SP site(s); (3) Deploying the solution to the target site(s).

The WSS SDK however does not explain in detail the target locations of the different types of files deployed on the server. In this post I am summarizing my observations that can help you understand what exactly happens during solution deployment.

I assume that WSS was installed in the default installation location, which for most WSS files is C:\Program Files\Common Files\Microsoft Shared\web server extensions\12 and for the virtual directories is C:\Inetpub\wwwroot\wss\VirtualDirectories\.


The Assemblies element contains a list of assemblies to be deployed to the SharePoint web server. These can be web parts, event handlers, web services or any other class that will be used in your application. The parameter DeplymentTarget determines whether to deploy the assembly to the GAC or to a directory (WebApplication).

With the GAC option assemblies are copied to C:\WINDOWS\assembly. With the WebApplication option the files are copied to C:\Inetpub\wwwroot\wss\VirtualDirectories\80\bin.

The SafeControl element is optional and if added SharePoint will put the assembly element to the SafeControls element in the web.config file of the target web application.


The Features element specifies files with feature definitions.

Target Folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\

Template Files

This is where most files will be added, including images, themes, web pages etc.

Target Folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\

Application Resources

In this section are listed resource files specific to the target web application.

Target Folder: C:\Inetpub\wwwroot\wss\VirtualDirectories\{virtual app port}\resources\

Global Resources

The resources list contains global resources available to all web applications.

Target Folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\

Root Files

Target Folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\

Web Parts

To list the web parts to be deployed use the DwpFile(s) elements to specify the name of the file.

Target Folder: C:\Inetpub\wwwroot\wss\VirtualDirectories\80\wpcatalog\

Site Definitions

The SiteDefinitionManifests list contains descriptions of all site definition folders. The Location attribute defines the name of the folder that contains the site definition. This folder contains the ONET.xml and other components of the site definition.

Target Folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates\