Ok, so you’ve set up your portal, and you’ve created a custom security policy so that you can run web parts without giving full trust to the entire portal. So, you’re ready to start writing web parts, right? Sure, but there is still more that you can do to protect you web parts from attack, as well as protect your portal from poor code – not that we ever write any poor code. J We can still add a little additional insurance with the help of the .Net Framework 2.0 Configuration Tool.

The problem that I have found with creating custom trust policies for my portal is that I have to grant full trust to the assemblies in my portal’s \bin directory. So now I don’t have to worry about my assemblies not having the required permissions, but what about all those permissions that .NET will now grant the assemblies that I don’t need. Also, since they are now running in a fully trusted mode, I can’t even use CAS (code access security) to refuse unwanted permissions.

Let’s step back for a second and take a look at how permissions are assigned to assemblies in .NET. When using the framework (at least in version 2.0), you can’t simply assign permissions (or refuse them for that matter) to an assembly. Each assembly that you create has certain pieces of “evidence” attached to it such as the ones on the following list:

Types of Evidence

·         The application directory that contains the assembly

·         A cryptographic hash of the program

·         Whether or not the assembly is installed in the GAC

·         Digital signature of the publisher

·         The site where the assembly was downloaded from

·         *The strong name of the assembly

·         The URL where the assembly was downloaded from

·         The zone that the assembly is running in

·         Zones include Internet, Intranet, My Computer,

·         Trusted and untrusted sites

This evidence is used to assign an assembly to a specific Code Group. Code groups exist to relate assemblies to permission sets, and permission sets are just groups of permissions. The evidence that your assembly contains – such as it’s strong name or web address– can grant membership to more than one Code group, and therefore more than one permission set. If this happens, the assembly receives the union of the all permission sets that its Code groups assign to it. Hope this makes sense so far, but if not there is a lot of information written on the web about this subject.

In order for this solution to work for you, you’ll have to have the .NET 2.0 SDK installed on your portal server. This is a little unfortunate if you’re as pressed for space as I am, but installing the SDK is the only way I know to get access to the .NET 2.0 Configuration Tool, and that is by far the simplest way to create a code group. There is a command line tool that can do the things that I demonstrate here. It’s called caspol, code access security policy tool, but its use won’t be discussed here. Also, in order to use the exact steps that I’m about to outline, you’ll need to provide a strong name for your assemblies. Here’s a good article for strong naming .NET assemblies http://www.codeguru.com/columns/experts/article.php/c4643/#more for those who need help.

Open up the .Net Framework 2.0 Configuration Tool on the machine which contains your portal.

Expand ‘My Computer’ -> ‘Runtime Security Policy’ -> ‘Machine’ -> ‘Code Groups’

Right click ‘All Code’ and select ‘New’

Right click ‘All Code’ and select ‘New’

Select ‘Create a new code group’

Select ‘Strong Name’ for the condition type, click the import button, and then select a web part assembly that has been strong named. The wizard will extract the public key for you.

Now just click ‘Finish’ and your code group is created.

1. Now that we have our Webpart code group and it’s attached ‘Everything’ permissions, we’re ready to exclude unwanted permissions.

1. Include System.Security.Permissions namespace in your web part class

1. To remove unwanted permissions just add one or more of the following attributes after your imports (or using) statements.

The follow code snippet shows a web part class with unwanted permissions removed:

Hope this helps. :)