Very often when working with a team of developers you build not one but multiple .NET assemblies containing Web Parts that are deployed in the private application folder (BIN) of the IIS Web Application. Deploying in the BIN folder results in the assemblies depending on the trust level configured by the administrators in the web.config that is in place for the IIS Web Application. Setting this trust level to FULL will solve all of the possible security problems for the deployed assemblies but this is not directly a good choice in a production environment. In most cases, the trust level is set to WSS_Minimal and best practice for a developer is to include in the manifest.xml, which is part of the SharePoint Solution (the .WSP), a blob of CAML asking the administrator to grant the required permissions for the proper working of the Web Part.

Daniel Larson has a good overview of the steps that are required.

Here is a sample of a possible custom CAS entry in the manifest.xml where the Web Part requests access to the SharePoint object model and the permission to communicate with a Web Service.

   1: <CodeAccessSecurity>

   2:     <PolicyItem>

   3:         <PermissionSet class="NamedPermissionSet" version="1" 

   4:          Description="My webpart's permission set">

   5:             <IPermission class="AspNetHostingPermission" version="1"

   6:                 Level="Minimal"/>

   7:             <IPermission class="SecurityPermission" version="1"

   8:                 Flags="Execution" />

   9:             <IPermission version="1" Unrestricted="True" 

  10: class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, 

  11: Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

  12:             <IPermission class="System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, 

  13: PublicKeyToken=b77a5c561934e089" Unrestricted="True" 

  14:             version="1">

  15:                 <ConnectAccess>

  16:                     <URI uri="$OriginHost$"/>

  17:                     <URI uri="http://springfield:95/webservices/.*"/>

  18:                 </ConnectAccess>

  19:             </IPermission>

  20:         </PermissionSet>

  21:         <Assemblies>

  22:             <Assembly Name="WeatherwebPart" Version="1.0.0.0" PublicKeyBlob="0x002400000480000094000

  23: 00006020000002400005253413100040000010001000DAF8ED8D945CD2ABB2EE7953A6039B791A725F11B4588AC6D70B3E06

  24: 48F955E9ED4C3C43CB044B8B0E8A6FF4D4FFBE9E3B9297D45F688A7264534E12414E17539305207EC961DA94DF294E7722CC

  25: D9BDBFC95A896E996F57156705D281EC39280BD604E87724556AF5807D146963F19F5B43DB69E1F22695463153A553260D2" />

  26:         </Assemblies>

  27:     </PolicyItem>

  28: </CodeAccessSecurity> 

Note that the Assembly element is set to the full details of the Web Part assembly. You can also have only the name of the assembly defined here (not including the full key). When the solution is deployed in the farm, the targeted IIS Web Application web.config will have the trust level set to a custom config file with the content of the WSS_Minimal.config (assuming that was the level before the deployment) and the contents you see above.

At U2U we are currently creating new Features for administrators working with SharePoint solutions. For example, we have a page like this that shows the full details of the solution in the SharePoint 3.0 Central Administration, showing also the custom CAS policy that is requested in the WSP. (More on this new project later)

Assume now that there is the request to create 20 more solutions like this and these assemblies also need specific permissions. It is not such a good idea to come up for each of them with their own CAS policies like shown above. If you sign them all with the same SNK file, you have enough with one configuration containing all of the permissions for all of the individual assemblies that are required. You could push this out in the farm with a solution dedicated to this with only the custom permission settings. The Assembly element then should only contain the PublicKeyBlob, not anymore a Name and a Version attribute.

   1: <Assemblies>

   2:   <Assembly PublicKeyBlob="0x002400000480000094000

   3: 00006020000002400005253413100040000010001000DAF8ED8D945CD2ABB2EE7953A6039B791A725F11B4588AC6D70B3E06

   4: 48F955E9ED4C3C43CB044B8B0E8A6FF4D4FFBE9E3B9297D45F688A7264534E12414E17539305207EC961DA94DF294E7722CC

   5: D9BDBFC95A896E996F57156705D281EC39280BD604E87724556AF5807D146963F19F5B43DB69E1F22695463153A553260D2" />

   6: </Assemblies>

This is yet another reason to enforce the use of only a few SNK files in your SharePoint development projects and not allow SNK files to be created directly by the developers for each assembly they are signing.