• What is Code Acess Security?
• How and why does SharePoint interact with code access security?
• I'm an admin for a SharePoint server, why do I care?
• As a WebPart developer, should I care?

• The first part of the answer is because Asp.net v1.1 is able to work with partially trusted assemblies.  This is a change from Asp.net v1.0.  Thus, to be a good Asp.net v1.1 citizen, SharePoint needed to work with partially trusted assemblies.
  
  
• The second part of the answer is to provide the most secure default operating platform possible for custom code.  The newest incarnation of Web Parts required assemblies to be installed on the server.  Ensuring those assemblies can be locked down via code access security management was a key requirement.

How does SharePoint interact with code access security?

There is one definitive document on this very subject - Microsoft Windows SharePoint Services and Code Access Security (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_sp2003_ta/html/sharepoint_wsscodeaccesssecurity.asp).  The primary author is a cool dude...  ;-)

As an administrator, why do I care?  Isn't my deployment made more difficult by code access security?

• The number one benefit is the ability to control how much access a web part assembly has to your resources (i.e. registry, file system, sql servers, etc) regardless of user identity.
  
  
• Deployment may become more complex; however, I would counter that it's well worth your time and effort to fully understand how this security mechanism operates.  Tools such as wppackager help make deployment of web part assemblies and custom code access security permissions much more palatable.  As the SharePoint community grows, I fully anticipate more robust tools will come online.
  
  
• The flip side is that you take a shortcut and say one of two things:
  
  
• "just install it in the GAC, it will have Full trust and everything will work", or
• "just raise the trust level to Full"

I hear these "recommendations" all too often and, truth be told, this doesn't make me happy.  It's both a sloppy and insecure practice, especially if you do it because you don't want to learn about code access security.  Blindly granting Full trust, is no different than leaving your keys in the ignition after you've parked your car.  Full trust means the code can do ANYTHING it wants. 

Windows SharePoint Services recommends custom web part assemblies should be installed in the BIN.  There is only one server configuration where the recommendation changes - servers using IIS host header definitions (see my previous post).

Answer to first question - ABSOLUTELY. 

Answer to the second question - as a server admin considering your Web Part, you just lost my business.

As developer, take the time to understand what permissions are required to run your code.  Write them down, convert them to a custom permission set and include them in the setup and marketing materials.

 

Having a complete list of permissions ...

• makes it easier for administrators to understand what your code does and how it will, or will not, affect their servers, and
  
  
• potentially protects you when something goes bad and angry server admins are storming through the night with pitch forks and torches looking for someone to yell at.

On top of knowing what permissions you need, be smart... write code that knows how to deal with scenarios where the expected permissions haven't been granted.  Although you may provide an admin a list of cas permissions, it's really up to the admin to grant them. 

If a WebPart developer doesn't know what permissions are required, how can a server administrator trust that the WebPart won't ...

• do something not intended with a server resource (whether or not malicious), or
• blow up if the trust level is tightened down

Give the admin the option to operate your WebPart with Full trust, don't blindly require it.  Giving the admin this option will make the admin much receptive to concept of introducing your WebPart to the system.

Is it a real world scenario to require a list of code access security permissions? 

Yes.  I know of several large server systems where WebPart assemblies are throughly analyzed before they are even put on test servers (much less production servers).  Those requirements include a full listing of code access security permissions... saying "install it in the GAC" just won't do.

Let's look at the Syndication Generator WebPart.  The help document lists the following permissions: 

• AspNetHostingPermission.Minimal
• SecurityPermission.Execution
• SharePointPermission.ObjectModel

This is a contract between me, the developer, and you, the server admin.  It effectively says that the Syndication Generator WebPart only needs these 3 permissions to operate.  That's it.  Nothing else... it doesn't need access to the file system, databases, sockets, dns, registry, etc., etc. 

What happens if an admin has problems with his server and detects that an unknown web part has been deleting files from his system?  The contract effectvely says it couldn't have been the Syndication Generator.  The list of permissions makes it easy to eliminate my code as being at fault (especially if the part is operating with only those permissions).

Fun stuff.  Don't avoid code access security.  It's extremely helpful.

-Maurice