Creating Policy Files

If you are not satisfied with the number or scope of permissions granted by the WSS_Minimal and WSS_Medium security policy files-which is normal for SharePoint implementations-you have three options. You can set the trust level of the SharePoint virtual server to Full, install assemblies in the GAC, or create your own custom policy file. Setting the trust level of the SharePoint virtual server to Full affects all assemblies used by the SharePoint virtual server and is the least secure option. Installing assemblies in the GAC grants a higher level of permissions to your assembly than necessary (because most assemblies do not require a full permission set) and is thus less secure. In addition, it makes assemblies installed in the GAC available to all virtual servers on the server. Although creating custom policy files requires the most work of all options, it is the most secure and recommended approach.

Security Alert 

Be cautious when buying third-party Web Parts that require a full permission set to execute successfully. This is a sign that the software has not been designed carefully. You can be more lenient when it comes to deciding whether to use Web Parts that were developed within your company.

Start creating a new policy file by customizing one of the SharePoint security policy files. This way, if anything goes wrong, it is easy to switch back to a valid state on your server. In the following procedure, you will create a new policy file based on the existing WSS_Minimal security policy file. Then you will modify the new policy file and add the permission to use the SharePoint object model and ensure it applies to assemblies that have a specific strong name (for example, your company strong name).

  1. Go the location where the WSS_Minimal security policy file (wss_minimaltrust.config) is located. By default, this is [drive letter]:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\.

  2. Copy WSS_Minimal.config, and rename the file [my policy].config.

  3. Open [my policy].config in Notepad.

  4. Locate the <SecurityClasses> section, and add the following code:

     <SecurityClass Name="SharePointPermission" Description="Microsoft.SharePoint .Security.SharePointPermission, Microsoft.SharePoint.Security, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c"/> 

  5. Locate the <PermissionSet> element that has a Name attribute with the following value: SPRestricted.

  6. Copy this element and all of its children, and paste it directly below the <PermissionSet> element.

  7. Set the name attribute of the new <PermissionSet> element to [custom permission set].

  8. Add the permission to use the SharePoint object model to the new permission set by adding the following code to the <PermissionSet> element:

     <IPermission  version="1"   ObjectModel="True" /> 

    The complete permission set looks like this:

     <PermissionSet  version="1"   Name="[custom permission set]">   <IPermission  version="1"     Level="Minimal" />   <IPermission  version="1"     Flags="Execution" />   <IPermission  version="1"     Connections="True" />   <IPermission  version="1"     ObjectModel="True" /> </PermissionSet> 

At this point, you have defined a new permission set that grants code a number of permissions, such as granting code the permission to use the SharePoint object model. Next, you will create a new code group that specifies that this permission set is granted to assemblies that have a specific strong name by using the StrongNameMembershipCondition membership condition. Because the root code group in the security policy file is a FirstMatchCodeGroup, the .NET CLR will stop assigning permissions when the first match to a child code group is found. Therefore, to be sure that the new code group is applied, you must declare the new code group as the first child code group:

  1. Add the following code directly below the root code group:

     <CodeGroup  version="1" PermissionSetName="[custom permission set]">   <IMembershipCondition    version="1" PublicKeyBlob="[public key blob]"   Name="MyAssemblyName" /> </CodeGroup> 

  2. Retrieve the public key blob from an assembly by issuing the following command from the Visual Studio 2005 command prompt:

     secutil.exe -hex -s [MyAssembly].dll 

  3. Copy the public key blob, and add the value to the PublicKeyBlob attribute of the <IMembershipCondition> element.

You have finished creating a custom security policy file.

In the next step, you need to adjust the Web.config file of your SharePoint virtual server so that it will use this custom security policy file. You can accomplish this by following these steps:

  1. Open the Web.config file of your SharePoint virtual server, and locate the <SecurityPolicy> section.

  2. Add the following code to this section:

     <trustLevel name="MyCustomTrustLevel" policyFile="[my policy].config" /> 

  3. Locate the <trust> element, and let it refer to the new custom trust level, as shown in the following code listing:

     <trust level="MyCustomTrustLevel " originUrl="" /> 

  4. Open a command prompt, and type iisreset to apply the custom policy file to the SharePoint virtual server.


If you omit this last step, you might receive an error when accessing a SharePoint site, stating that the assembly security permission grant set is incompatible.

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: