Home > MOSS 2007 > Behind the Scences: CAS in Solution Packages

Behind the Scences: CAS in Solution Packages

December 31st, 2008 Leave a comment Go to comments

As I always mention in my presentations and articles (such as this one), I’m not too crazy about deploying everything to Bin folder (OverCASing). I believe There is a place for everything! Honestly , many stuff in SharePoint don’t work when executed from bin folder and more importantly, there are customers out there that don’t care (read it , they don’t want to pay for it !). I am not going to walk you through this discussion at all.

On the other hand, I know that there are many resources out there that talk about pros and cons of utilizing code access security in your solution packages and run your Web part assemblies (or your code in general) in a super sandbox mode, a.k.a Partially trusted environment. What I haven’t seen though is a complete explanation of what happens behind the scenes when you include code access security in your solution manifest file and what gets changes , where and when, a solution containing CAS settings gets deployed or retracted. I was mostly interested to see what happens when the solution package gets retracted.

Any Code that runs from the bin directory of an IIS Web application (SharePoint Web application is an IIS Web site all together) runs in a secure mode; therefore you have to explicitly give it the permissions it requires to function. Easiest solution (FWIW, the most stupid one ) is to raise the trust level of your Web application to full (in the Web.config file).The recommended approach is to elevate the permissions of the assembly by creating a new security policy file and point your web.config file to it. Thankfully, by using solution package concept, SharePoint provide a way for automating this process for ya.After you create a SharePoint Web application its Web.config looks like this:

Note: Only the sections of the web.config file that are related to this topic were included below.

[Xml]



[/Xml]

Brief explanation of each node:

SafeControls: A list of all approved controls that are considered as safe for invocation in any SharePoint context.
SecurityPolicy node: A collection of mappings between security policy files (stored at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config) and the trust level names for the security policy files. If you want to add more config files and name them whatever you want, be my guest!
Trust node: Configures the level of code access security (CAS) that is applied to the entire Web application.Please note the word “the entire” Web application here. This means that if let’s say for a simple Web part , you raise this to Full , your entire Web application will be running in full trust. I am sure I don’t need to remind you, how crazy that would be.

Let’s suppose , you have an assembly called SharePoint.MyControls.dll which contains all the controls you like to deploy to the bin folder and apply CAS to it. So what would do ? Good question!

1) First, you develop the bad boy! 🙂

2) Then the SafeControl and CodeAccessSecurity entries should be added to the Manifest.xml file for granting permission to the assembly (and all controls in it). This will generate and applies the necessary changes in the Web Application and security config folder to run your assembly with the the necessary permissions. Obviously the CAS settings you define in the Manifest.xml file depends on the permissions your assembly requires. There is this .Net framework tool called Permission Calculator Tool (Permcalc.exe) that is used to determine what permissions your assembly requires to be deployed to bin folder. It is a handy tool!

Directives.ddf
[Xml]
; ALL FILES MUST BE EXPLICITLY REFERENCED HERE
.OPTION EXPLICIT ; Generate errors
.Set CabinetNameTemplate=MembershipBase.wsp
.set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
.Set CompressionType=MSZIP;** All files are compressed in cabinet files
.Set UniqueFiles=”ON”
.Set Cabinet=on
.Set CabinetFileCountThreshold=0
.Set FolderFileCountThreshold=0
.Set FolderSizeThreshold=0
.Set MaxCabinetSize=0
.Set MaxDiskFileCount=0
.Set MaxDiskSize=0
.Set DiskDirectory1=Package
;Files to place into the CAB Root
Manifest.xml
Deployment\SharePoint.MyControls.dll
;***
[/Xml]

Manifest.xml
[Xml]





























[/Xml]

Okay , now let’s see what happens behind the scenes :

A) Solution package is deployed :
1) Security config folder: A new security policy file was created called wss_custom_wss_minimaltrust.config copying the content from wss_minimaltrust.config file and adding the new policy item defined in the Manifest.xml file.Additionally backup files were created (wss_minimaltrust.bak and wss_custom_wss_minimaltrust.bak). In this case the new custom policy file was created from wss_minimaltrust.config,remember in the Web application’s web.config file, the initial trust level was Minimal so this makes sense all together.

2) Web Application: the web.config file was changed the assembly was added as SafeControl. Additionally A new SecurityPolicy entry was defined and a backup file was created (web.bak).

[Xml]




[/Xml]

Obviously SharePoint.MyControls.dll assembly is copied to the the bin folder of the Web Application.

B) Solutioin package is retracted:

1) Security Config Folder: wss_custom_wss_minimaltrust.config file was changed; the new PolicyItem information defined in the Manifest.xml file was removed. Additionally a backup file was created.

2) Here is the most important thing and 90% , the reason I decided to write this post:

Web Application: When solutoin package was retracted, the web.config file was again changed. Obviously, the SafeControl node for the SharePoint.MyControls.dll assembly was removed. The trust level continued to be WSS_Custom, because once our CAS stuff is taken out of that file (wss_custom_wss_minimaltrust.config) , the content is the same as it was initially, meaning wss_minimaltrust.config file. Additionally a backup file was created.

3) The bin folder: SharePoint.MyControls.dll assembly was removed.

Categories: MOSS 2007 Tags:
  1. December 31st, 2008 at 21:08 | #1

    Reza,

    Nice walkthrough.

    Partially trusted code… we have had years to get used to it and it is still being ignored and “worked around”. Going forward its just going to be more important “cloud computing” anyone?

    /Jonas

  2. Reza Alirezaei
    January 1st, 2009 at 20:17 | #2

    I guess that’s gonna be a good discussion! a)Cloud computing . b)performance and c)security! I will put something together soon….

  3. Shahrzad
    January 3rd, 2009 at 21:28 | #3

    Reza,

    this is a great observation! thanks for sharing…

  4. Paul Siu
    April 21st, 2009 at 07:00 | #4

    Thank you so much for sharing that observation. I have been wondering why some of the WSS have WSS_min based custom files and others have WSS_med custom files.

  5. Amit
    August 2nd, 2009 at 07:31 | #5

    Really good walk through in details.
    gr8 post