Securing Web Parts in SharePoint Foundation

Applies to: SharePoint Foundation 2010

Web Parts in Microsoft SharePoint Foundation provide a powerful way for users to interact with other systems. SharePoint Foundation 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

Web Parts can also be created in a sandboxed solution. By default, a sandboxed solution has restricted access to the underlying system. This provides greater security and monitoring of the Web Part. For more information about sandboxed solutions, see Sandboxed Solutions in SharePoint 2010.

Code Access Security

Code Access Security (CAS) is a resource-constraints policy that limits the access that an assembly has to protected system resources and operations. SharePoint Foundation has built-in security policies built on top of the built-in security policies of ASP.NET. By default, SharePoint Foundation 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. You can create a custom CAS policy for your Web Part, or 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 SharePoint Foundation.

Built-In Security Settings

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

  • WSS_UserCode

  • WSS_Minimal

  • WSS_Medium

These trust levels extend the ASP.NET trust levels for use with SharePoint Foundation. Trust levels are defined in policy files that can be found on the file system of each Web server.

Important   By default, the built-in SharePoint Foundation policy files in SharePoint Foundation, named wss_usercode.config, wss_minimaltrust.config, and wss_mediumtrust.config, are found in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG directory.

By default, SharePoint Foundation 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 SharePoint Foundation 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_Medium, WSS_Minimal and WSS_UserCode policy files in the ASP.NET 2.0 environment.

Permission

WSS_Medium

Trust Level

WSS_Minimal

Trust Level

WSS_UserCode (SandBoxed Solutions)

Trust Level

System.Web.AspNetHostingPermission

Medium

Minimal

Minimal

System.Net.DnsPermission

Unrestricted=”True”

None

None

System.Security.Permissions.EnvironmentPermission

Read=”TEMP; TMP;USERNAME;OS;COMPUTERNAME”

None

None

System.Security.Permissions.FileIOPermission

Read, Write, Append, PathDiscovery, Application Directory

None

None

System.Security.Permissions.IsolatedStorageFilePermission

AssemblyIsolationByUser, Unrestricted UserQuota

None

None

PrintingPermission

Default printing

None

None

System.Security.Permissions.SecurityPermission

Assertion, Execution, ControlThread, ControlPrincipal, RemotingConfiguration

Execution

Execution

Microsoft.SharePoint.Security.SharePointPermission

ObjectModel=”True”

None

ObjectModel=”True”, UnsafeSaveOnGet=”True”

System.Net.Mail.SmtpPermission

Access=”Connect”

None

None

SqlClientPermission

Unrestricted=”true”

None

None

WebPartPermission

Connections=”True”

Connections=”True”

None

WebPermission

Connect to origin host (if configured)

None

None

Note

For more information about Code Access Security, see Using Code Access Security with ASP.NET and also Security Guidelines for .NET Framework 2.0.

Creating a Code Access Security Policy

SharePoint Foundation has the ability to deploy a CAS policy file with a solution. We recommend that you use the permissions for sandboxed solutions as listed in the wss_usercode.config file, but you can also create custom permissions for your Web Parts and use SharePoint Foundation to handle the deployment.

The following code example shows the basic structure of a CAS policy file in a SharePoint Foundation 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 (Solution).

When you deploy your assembly using a custom CAS policy, you must use the -CASPolicies option with SharePoint Management Shell. The command is as follows:
Install-SPSolution –Identity <insert name> -CASPolicies <true/false>

See Also

Other Resources

Using Code Access Security with ASP.NET