Configuring Security Settings in the Web.config File

The default security settings in the Web.config file of a SharePoint virtual server allow only a minimum amount of freedom-which makes a lot of sense considering the SD3+C initiative. This section explains the security-related configuration settings in a SharePoint Web.config file.

The SafeControls Section

The first security-related setting is the <SafeControls> section. Before you can add Web Parts to Web Part pages, administrators have to make the server trust a Web Part. This is done by adding a <SafeControl> element to the <SafeControls> section. Each <SafeControl> entry identifies a trusted assembly.


In a typical SharePoint installation, many of the trusted assemblies found in the <SafeControls> section are Web Part libraries that contain one or more trusted Web Parts.

A <SafeControl> element has four attributes. The following code listing shows a <SafeControl> entry that allows all Web Parts belonging the System.Web.UI.WebControls namespace and are located in the System.Web assembly to be added to Web Part pages:

 <SafeControls>   <SafeControl Assembly="System.Web, Version=1.0.5000.0, Culture=neutral,   PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.WebControls"   TypeName="*" Safe="True" /> </SafeControls> 

The first attribute of a <SafeControl> entry is the Assembly attribute. This attribute identifies the assembly name of the assembly that contains the Web Parts. This name can be partially or fully qualified. If an assembly is partially qualified, this attribute contains only the name of the assembly. For example, this name is System.Web for an assembly that is named System.Web.dll. A fully qualified assembly name consists of four parts: the assembly name, version number, culture (which is always set to neutral for code assemblies), and the developer identity (a public key token). The following name is the name of the Microsoft.SharePoint assembly and is an example of a fully qualified assembly name: "Microsoft.SharePoint, Version=, Culture=neutral, PublicKey Token=71e9bce111e9429."


Although you can add entries for partially qualified assemblies in the SafeControls list, it is recommended that you use fully qualified assembly names. This makes it easier to define security policies that are based on content-based evidence. In addition, if you choose to use strong-named assemblies consistently, the .NET Framework behaves consistently too. The .NET assembly resolver, which is responsible for deciding in which locations to look for a given assembly and decides which assembly version to load, acts quite differently when it comes to finding fully or partially qualified assemblies. In the real world, a lack of understanding of those differences now and then leads to problems where the assembly that is actually loaded differs from the one the administrator or developer expects.

image from book

Real World Establishing the Version Number of Referenced Assemblies

If you are not sure which version of an assembly is used by a .NET application, you can use the ILDASM (Intermediate Language Disassembler) .NET Framework tool. ILDASM is installed automatically as a part of every Visual Studio 2005 installation. If you open ILDASM, you can choose File, then Open and browse to the .NET application you want to investigate. This opens the .NET application in ILDASM. Double-click on the Manifest node to open the .NET assembly manifest. The assembly manifest contains information about the assemblies that are referenced within the .NET application. Assembly references are preceded by the extern keyword. The following code listing shows a part of a .NET assembly manifest containing a reference to the Microsoft.SharePoint assembly.

 .assembly extern Microsoft.SharePoint {   .publickeytoken = (71 E9 BC E1 11 E9 42 9C)   // q.....B.   .ver 12:0:0:0 } 

image from book

The second attribute of a <SafeControl> entry is the Namespace attribute. This contains the value for the .NET namespace for the Web Part. By convention, this name is often equal to the assembly name, although this does not have to be so. The correct value for this namespace can be retrieved by looking at the code itself. In C#, the namespace value is identified by the namespace keyword. The following code listing shows a code fragment with a namespace value of MyNamespace:

 namespace MyNamespace {   class MyClass : WebPart   {     …   } } 

The third attribute of the <SafeControl> element is TypeName. The TypeName attribute specifies the Web Part class name. In C#, the class name is identified by the class keyword. The previous code listing shows a code fragment with the following type name: MyClass. You can also use an asterisk (*) to include all Web Part classes within the specified assembly and namespace.

The fourth attribute of the <SafeControl> element is Safe. By default, this attribute is set to True, so you can omit this attribute if you want. The Safe attribute needs to be set to True to make a Web Part trusted. Administrators can use this attribute and set it to False to ensure a Web Part is temporarily unavailable. This attribute is optional.

The final attribute of the <SafeControl> element is AllowRemoteDesigner. By default, this attribute is set to True. This optional attribute can be used to determine if a control can be manipulated via a remote designer such as Microsoft Office SharePoint Designer.

The securityPolicy Section]

The <securityPolicy> section is located in the <system.web> section. The <securityPolicy> element defines a collection of mappings between security policy files and the trust level names for those security policy files. In ASP.NET, you can choose to use the special Full trust level. This trust level is equivalent to having full trust in the local machine zone; it allows ASP.NET applications to perform all operations. If you specify the Full trust level, the ASP.NET host does not apply any additional policies. Setting the trust level to Full on a SharePoint server is incompatible with the intentions of the SD3+C initiative, making a SharePoint installation less secure by default.

image from book

Real World Web Part Permissions

Often a Web Part developer claims the trust level of the virtual server needs to be raised to Full because the Web Part requires additional permissions. Although doing so is easy, when it comes to securing your server, this is not the time to get lazy. If a Web Part does require additional permissions, make sure to obtain exact specifications of the permissions that are needed. Then create a custom security policy file to cater to these needs.

image from book

The <securityPolicy> section, a child of the <system.web> element, contains a collection of <trustLevel> elements that can be used to define custom security policy files. <trustLevel> elements are also used to define two security policy files that are shipped with SharePoint installations: WSS_Minimal and WSS_Medium. This is shown in the following code listing:

 <securityPolicy>   <trustLevel name="WSS_Medium" policyFile="   C:\Program Files\Common Files\Microsoft Shared\   Web Server Extensions\60\config\wss_mediumtrust.config" />   <trustLevel name="WSS_Minimal" policyFile="   C:\Program Files\Common Files\Microsoft Shared\   Web Server Extensions\60\config\wss_minimaltrust.config" /> </securityPolicy> 

The trust Element

The final Web.config setting that is important in specifying security settings is the <trust> element. The <trust> element configures the level of code access security applied to an application. By default, SharePoint applications run under the WSS_Minimal trust level. The following code listing shows the Web.config file of a SharePoint virtual server that runs under the default trust level of WSS_Minimal:

 <trust level="WSS_Minimal" originUrl="" processRequestInApplicationTrust="false" /> 

The level attribute is used to set the name of the security policy file under which the application will run. The originUrl attribute can be used to define a well-formed URL that specifies the origin of an application. This attribute is useful in scenarios where origin-based evidence is important. The processRequestInApplicationTrust attribute specifies whether page requests are automatically restricted to the permissions that are configured in the trust policy file. If this attribute is set to true, the Page class uses the PermitOnly stack walk modifier on the ASP.NET permission set. In such scenarios, granting extensive permissions via a policy files is useless. If this attribute is set to false, only the security policy will be applied (instead of the intersection between the ASP.NET permission set and the security policy file). If you need more information about the PermitOnly stack walk modifier, refer to the "Stack Walk Modifiers" section.

Best Practices 

In SharePoint environments, always set the processRequestInApplicationTrust attribute to false. This is the default value for SharePoint environments; the default value for ASP.NET applications is true. If you do not set this attribute to false, creating custom security policy files is useless because the only permission set that will be applied to your code when the processRequestInApplicationTrust attribute is set to true is the ASP.NET permission set.

Microsoft Office Sharepoint Server 2007 Administrator's Companion
MicrosoftВ® Office SharePointВ® Server 2007 Administrators Companion
ISBN: 0735622825
EAN: 2147483647
Year: 2004
Pages: 299

Similar book on Amazon
Microsoft Office SharePoint Server 2007 Best Practices
Microsoft Office SharePoint Server 2007 Best Practices
Microsoft SharePoint 2010 Administrator's Companion
Microsoft SharePoint 2010 Administrator's Companion
Professional SharePoint 2010 Administration
Professional SharePoint 2010 Administration
Inside Microsoft  Office SharePoint  Server 2007
Inside Microsoft Office SharePoint Server 2007 © 2008-2017.
If you may any questions please contact us: