Good news and better news for deploying Code Access Security policies within SharePoint v3... :)

First...

A big thank you ... no, make that a huge thank you ... goes out to everyone that voiced their opinions on this blog, at TechReady, PDC, etc!!  Your comments about the difficulty of deploying code access security policies with your WebPart assemblies helped shape a feature that was long overdue within WSS.

Now for the good news... 

WPPackager is going away.  Bad new... sort of.  However, there is a silver lining. The core functionality of deploying code access security policies has been integrated into v3's Solution deployment engine.

And the even better news...

You will be able to deploy CAS policies starting with Beta 2 TR.

That's right!  The development community will have a way of deploying CAS policies natively within SharePoint.  You will no longer be required to rely on a (buggy) tool.  Oh Yeah!!!

Here's a quick rundown of the CAS deployment capability in v3...

1. It's very similar to the protocols established by wppackager.  If you haven't read the wppackager documentation in awhile, it might be helpful to briefly review them.
2. It's just another deployment feature of the Solutions architecture.  If you haven't considered deploying your WebPart assemblies via Solutions, now is the time to reconsider. :)
3. Unlike wppackager, the new CAS Solutions deployment model will allow you to specify multiple policies within a single Solution package.
4. You can associate policies to either signed or unsigned assemblies.  Although similar functionality existed with wppackager, it was not widely known.  Depending on how you form your Solution manifest, the resulting CodeGroups within the trust file will utilize either StrongNameMembershipCondition or UrlMembershipCondition classes.

What does the schema look like? 

A quick example is in order ... note the yellow highlighted section ...

Schema rules:

1. There can only be 1 CodeAccessSecurity node per Solution manifest.
2. There can be any number of PolicyItem nodes.
3. Each PolicyItem node can contain only 1 PermissionSer and Assemblies node.
4. Each PermissionSet node can contain any number of IPermission nodes
5. Schema of IPermission nodes are defined by the .NET framework
6. Each Assemblies node can contain any number of Assembly nodes. 
7. The CodeAccessSecurity/PolicyItem/Assemblies/Assembly node is different than the Solution/Assemblies/Assembly node.
8. The Assembly node can contain any of the following attributes:
   • Name
   • Version
   • PublicKeyBlob

Commands to add and deploy your Solution which contains a code access security policy...

Add: stsadm.exe -o addSolution -filename "InstallAssemblies_Solution_2052225630.cab"
Deploy: stsadm.exe -o deploySolution -name "InstallAssemblies_Solution_2052225630.cab" -allcontenturls -local -force -allowCasPolicies

Note that stsadm.exe will require the use of the -allowCasPolicies flag for Solution packages that contain CAS policies.

What does the trust file look like once the Solution has been deployed?

If you were to use the manifest file from above, the policy file will look like the following file... again note the yellow highlighted sections...

From manifest to trust file... what happened?

1. The PermissionSet from the PolicyItem is directly inserted into the trust file (the first yellow highlighted section).  In this example, the PermissionSet is named "installassemblies_solution_2052225630.cab-b172f003-d6c7-3e13-f737-a5d84a02e3e5-1".  The name is a combination of the installation package ("installassemblies_solution_2052225630.cab") plus the SolutionId ("b172f003-d6c7-3e13-f737-a5d84a02e3e5") plus the PolicyItem index (in this case there is only 1 PolicyItem).
2. For each Assembly associated with a given PolicyItem in the manifest, one (1) CodeGroup (the second yellow highlighted section) is created. Each CodeGroup will reference the associated PermissionSet within the PolicyItem. Additionally, each CodeGroup is inserted in the first position of the parent CodeGroup container.  This ensure the FirstMatchCodeGroup behavior allows custom policies to be honored before the default WSS permission sets are applied.

Now let's look at how the CodeGroups are created based on the data within the manifest file...

As mentioned in the schema rules section above, the Solution\CodeAccessSecurity\Assemblies\Assembly node can contain three attributes: Name, Version and PublicKeyBlob.  The combination of the three attributes determine which Membership class is used.

Finally - reliable, supported deployment of code access security policies is now available in WSS. :)

-Maurice