Securing Web Parts in Windows SharePoint Services

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Web Parts in Windows SharePoint Services provide a powerful way for users to interact with other systems. Windows SharePoint Services has built-in security settings to restrict the access that a Web Part has to underlying systems. A developer can create custom security policy files to give a Web Part greater access to the underlying system. This topic introduces the built-in settings, an overview of a Code Access Security (CAS) policy, and how to include a custom Code Access Security policy in a Windows SharePoint Services solution.

Code Access Security

Code Access Security is a resource-constraints model that limits the access that an assembly has to protected system resources and operations. Windows SharePoint Services has built-in security policies built on top of the built-in security policies of ASP.NET. By default, Windows SharePoint Services uses a minimal set of permissions in order to protect the server and underlying infrastructure from malicious code.

If your Web Part needs greater access than what is provided in the minimal settings, there are a number of ways to increase the permissions of your Web Part, but only one is recommended. The recommended practice is to create a custom Code Access Security policy for your Web Part. The second method is to increase the overall trust level of the server farm in the web.config file. This is a security risk and is not recommended. For more information about deployment, see Deploying Web Parts in Windows SharePoint Services.

Built-In Security Settings

Windows SharePoint Services is a partial trust application by default. Windows SharePoint Services can use the ASP.NET built-in trust levels but defines two trust levels of its own:

• WSS_Minimal

• WSS_Medium

The trust levels extend the Minimal and Medium trust levels of ASP.NET for use withWindows SharePoint Services. Trust levels are defined in policy files found on the file system of each web server.

Important   By default, the built-in Windows SharePoint Services policy files, named wss_minimaltrust.config and wss_mediumtrust.config, are found in %SYSTEMDRIVE%\Program Files\Common Files\Microsoft Shared\web server extensions\12\config.

By default, Windows SharePoint Services applies the WSS_Minimal trust level for the virtual server. This trust level grants all of the permissions in the ASP.NET Minimal trust as well as Web Part connections. The WSS_Minimal policy restricts the Web Part from accessing many resources for advanced operations, including the object model and file operations.

The WSS_Medium trust level grants greater access to the environment. Also, WSS_Medium allows access to the Windows SharePoint Services object model and file operations including read, write, append, and path discovery. This trust level also allows access to environment variables.

The following table outlines the specific permissions granted with the WSS_Minimal and WSS_Medium policy files in the ASP.NET 2.0 environment.

Creating a Code Access Security Policy

Windows SharePoint Services 3.0 added the ability to deploy a CAS policy file with a solution. This feature makes it easier for you to create custom permissions for your Web Parts and allows Windows SharePoint Services to handle the deployment.

The following code example shows the basic structure of a CAS policy file in a Windows SharePoint Services solution package.

<CodeAccessSecurity>
   <PolicyItem>
     <PermissionSet class="NamedPermissionSet" version="1"
      Description="Permission set for custom test WebParts">
        <IPermission class="AspNetHostingPermission" version="1" 
        Level="Minimal" />
        <IPermission class="SecurityPermission" version="1" 
        Flags="Execution" />
        <IPermission 
        class="Microsoft.SharePoint.Security.SharePointPermission, 
        Microsoft.SharePoint.Security, version=11.0.0.0, 
        Culture=neutral, PublicKeyToken=71e9bce111e9429c" version="1" 
        ObjectModel="True" />
        <IPermission class="System.Net.WebPermission, System, 
        version=1.0.5000.0, Culture=neutral, 
        PublicKeyToken=b77a5c561934e089" version="1">
          <ConnectAccess>
            <URI uri="https?://.*" />
          </ConnectAccess>
        </IPermission>
        <IPermission 
        class="System.Security.Permissions.SecurityPermission, 
        mscorlib, version=1.0.5000.0, Culture=neutral, 
        PublicKeyToken=b77a5c561934e089" version="1" 
        Flags="ControlThread, UnmanagedCode" />
        <IPermission 
        class="System.Security.Permissions.EnvironmentPermission, 
        mscorlib, version=1.0.5000.0, Culture=neutral, 
        PublicKeyToken=b77a5c561934e089" version="1" Read="UserName" />
     </PermissionSet>
     <Assemblies>
       <Assembly PublicKeyBlob=PublicKeyBlob />
     </Assemblies>
   </PolicyItem>
</CodeAccessSecurity>

The list below includes some general guidelines that apply when you use a <CodeAccessSecurity> section in your solution manifest.

• There can only be one <CodeAccessSecurity> per solution manifest.

• There can be multiple <PolicyItem> nodes.

• Every <PolicyItem> node can only contain one <PermissionSet> node.

• Every <PolicyItem> node can only contain one <Assemblies> node.

• Each <PermissionSet> node can contain multiple <IPermission> nodes.

• There can be multiple <Assembly> nodes under the <Assemblies> node.

For more information about the schema of the <CodeAccessSecurity> area, see CodeAccessSecurity Element.

When you deploy your assembly using a custom CAS policy, you must use the -allowCasPolicies option with the stsadm.exe utility. The command is as follows:
stsadm -o deploySolution -name <insert name> -allowCasPolicies

For more information about using stsadm to deploy a solution, see Stsadm Operations.

See Also

Other Resources

Using Code Access Security with ASP.NET

Stsadm Operations