Configure and deploy secure Web Parts to your server (Office SharePoint Server)

  • Article

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

Microsoft Office SharePoint Server 2007 comes with a set of Web Parts that site administrators can add to Web Parts pages after installing the product. However, your organization may need custom Web Parts. In that case, a developer would write custom-built ASP.NET 2.0 Web Parts and ask you to install them to a deployment of Office SharePoint Server 2007.

Office SharePoint Server uses some of the configuration management settings provided by the Microsoft .NET Framework. Some of these settings are stored in XML configuration files and provide a broad range of settings that allow server administrators to manage the Web application and its environment. For more information about ASP.NET 2.0 configurations files, see Machine.Config and Web.Config Explained (https://go.microsoft.com/fwlink/?LinkId=103450&clcid=0x409) in "Securing Your ASP.NET Application and Web Services" in the MSDN Library Online.

Configuration options

System administrators can deploy ASP.NET 2.0 Web Parts to a deployment of Office SharePoint Server in either of two locations:

  • Bin directory   Stored in your Web application root directory.

  • Global Assembly Cache (GAC)   All standard Web Parts are automatically installed with the common language runtime of the .NET Framework. Storage in the GAC enables you to share Web Parts across numerous applications. Components are typically stored at C:\WINNT\Assembly.

Each location has advantages and disadvantages, as described in the following table.

Deployment location Advantages Disadvantages

Bin directory

A partial trust location. By default, code that runs from this directory has a low level of code access security permissions. The administrator must explicitly raise permissions granted to a Web Part so that it can function properly. Because of this level of control and the in-depth defenses, administrators tend to prefer that assemblies run in the Bin directory, with a known set of required code access security permissions.

A Bin directory is also specific to a Web application. This makes it possible to isolate code to a particular Web application.

To run your Web Part everywhere, you must deploy your Bin assembly.

GAC

A global location where you can deploy signed assemblies. Assemblies run with full trust by default. They are installed globally, so they work in any Web application.

Generally, there are no code access security restrictions on code installed to the GAC; therefore, you lose the benefit of in-depth defense security.

Additionally, it can be difficult to deploy your program database (.pdb) files to assemblies in the GAC.

Setting special security attributes

ASP.NET 2.0 Web Parts that you store in the Bin directory have special constraints for security. You can choose whether to set special security attributes for your Web Part, depending on how you plan to use it.

The Bin directory is a partial trust location. Therefore, your Web Part does not automatically grant full trust code permissions when it is executed. Because the code that calls into your Web Part is granted only partial trust permissions, the Web Part developer must set the AllowPartiallyTrustedCallers attribute on your ASP.NET 2.0 Web Part.

Note

Marking a component as "safe" with the AllowPartiallyTrustedCallers attribute puts the responsibility for safe implementation on the developer.

Code access security permissions for the Bin directory are very low by default; only pure execution is allowed. You must almost certainly elevate these permissions to make your assembly run correctly.

You can elevate permissions in two ways:

  • (Recommended) Create a trust policy file and point your Web.config file at the new file. This option is more complicated, but it gives you precise permissions for your Web Parts. For more information about trust policy files, see Microsoft Windows SharePoint Services and Code Access Security (https://go.microsoft.com/fwlink/?LinkID=103436&clcid=0x409) in the MSDN Library Online.

  • Raise the overall trust level of the Bin directory. In the Web.config file in your application root directory, locate the trust element. The default value for the trust element's level attribute is WSS_Minimal. You can change this level to WSS_Medium. While this option is simpler, it grants arbitrary new permissions that you may not need, and it is less secure than creating a trust policy file.

Safe Controls list

A fundamental assumption of SharePoint Products and Technologies is that "un-trusted users" can upload and create .aspx pages within the system on which Office SharePoint Server is running. These users should be prevented from adding server-side code within .aspx pages, but there should be a list of approved controls that those un-trusted users can use. In Office SharePoint Server, this is provided by the Safe Controls list.

The Safe Controls list is a list of controls and Web Parts specific to your SharePoint site that server administrators can designate as safe for invocation on any .aspx page within a site. You store this list in the Web.config file in your Web application root.

Task requirements

The following is required to perform the procedures for this task.

  • Administrator privileges on a server computer that has one of the server products in the Office 2007 release installed.

To configure and deploy secure Web Parts to your server, you can perform the following procedures.