Configure Sharepoint code access security April 24, 2008

For everyone who ever written WebPart to access web service must have experiences to dealt with security problem. Writing a web part or web service may not be a big issue but deploying them is certainly a headache. You start getting permission errors as soon as you deploy your code on the server. Ok, here we go to do some action to avoid this annoying things. First there are three ways to that.

• Increase the trust level for the entire virtual Server
  Advantage: Implement this thing is very simple, no hardwork require.
  Disadvantage: Your application security becomes weak.
• Create a custom policy file for your assemblies
  Advantage: This method is the safest way, cause you only grant access to specific assembly.
  Disadvantage: You need to do some “vodoo dance” to make things works.
• Install your assemblies in the GAC
  Advantage: Implement this thing is very simple, no hardwork require.
  Disadvantage: This method is risky to implement.

I would prefer the second option, cause it is the safest way. Now, lets do some “vodoo dance”.

• Go to your Sharepoint config location.
  ex: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG
• Make a copy of wss_minimaltrust.config and rename it wss_customtrust.config.
• Open wss_customtrust.config file using any text editor.
• Change the name of the new PermissionSet element from ASP.Net to New_File_Name:

  Example (Before)

  <PermissionSet class=”NamedPermissionSet” version=”1″ Name=”ASP.Net”>
  <!– <IPermission> nodes omitted for clarity –>
  </PermissionSet>

  Example (After)

  <PermissionSet class=”NamedPermissionSet” version=”1″ Name=”New_File_Name“>
  <!– <IPermission> nodes omitted for clarity –>
  </PermissionSet>

• Add the following <IPermission> node to the<PermissionSet> element where the name attribute equals New_File_Name:
  <IPermission class=”SharePointPermission” version=”1″ ObjectModel=”True” />

  Therefore, the resulting customized <PermissionSet> will look as follows:

  <PermissionSet class=”NamedPermissionSet” version=”1″ Name=” New_File_Name“>
  <IPermission class=”AspNetHostingPermission” version=”1″ Level=”Minimal” />
  <IPermission class=”SecurityPermission” version=”1″ Flags=”Execution” />
  <IPermission class=”WebPartPermission” version=”1″ Connections=”True” />
  <IPermission class=”SharePointPermission” version=”1″ ObjectModel=”True” />
  </PermissionSet>>

• Once you define the customized element, you must create a code group to specify when the CLR should apply the permission set.

  In the following example, the membership condition for the new code group is based on strong name membership:

  <!– a custom group must precede the default ASP.NET code group –>
  <CodeGroup class=”UnionCodeGroup” version=”1″ PermissionSetName=”CustomPermissions”>
  <IMembershipCondition class=”StrongNameMembershipCondition” version=”1″ PublicKeyBlob=”… see note below …” Name=”MyAssemblyName” />
  </CodeGroup>

  Note To retrieve the public key blob for an assembly, use the secutil.exe tool as follows:

  secutil.exe -hex -s MyAssemblyName.dll

  For more information about secutil.exe, see Secutil Tool.

  In the following example, the membership condition for the new code group is not strongly name membership:

  You can specify membership conditions for a code group in several ways. You can use the UrlMembershipCondition to specify conditions as follows:

  <CodeGroup class=”UnionCodeGroup” version=”1″ PermissionSetName=”CustomPermissions”>
  <IMembershipCondition class=”UrlMembershipCondition” version=”1″ Url=”$AppDirUrl$/bin/MyAssemblyName.dll” />
  </CodeGroup>

• To grant permission for Webpart to access Web Service, add the following to the corresponding IPermission element in the appropriate policy file:
  <IPermission class=”WebPermission” version=”1″>
  <ConnectAccess>
  <URI uri=”…uri in the form of a regular expression…” />
  </ConnectAccess>
  </IPermission>>
• Save and close the file. The policy file is ready to use.
• Open the web.config file for the virtual server extended with Windows SharePoint Services and add the following <trustLevel> tag to the SecurityPolicy element:
  <trustLevel name=”WSS_CUSTOM” policyFile=”new_file_name.config” />

  In the web.config file, change the <trust> tag so that it refers to the newly defined trust level.

  <trust level=”WSS_CUSTOM ” originUrl=”" />

• Save and close the web.config file.
• Reset IIS, such as by using iisreset, to apply the custom policy to the specified virtual server.

Thats all our “vodoo dance”, a litle bit complicated but worthy enough. You can read complet/details tutorial from MOSS 2007 and Weblog FAQ. Click here to download source code of this tutorial.

Advertisement