Some History
One of the first things I learned related to the topic was that when one says they are using SharePoint, from an administrator or developer’s perspective that is not enough information. SharePoint, depending on a point in time since 2001, means either SharePoint Team Services (STS) or Windows SharePoint Services (WSS), and either SharePoint Portal Server (SPS) or Microsoft Office SharePoint Server (MOSS). Of course there are many other derivatives when you account for versioning and service packs, and which release of the ASP.Net framework you are developing against. To be clear, on my current project we are using the ASP.Net 3.0 framework to develop custom web parts for WSS 3.0 and MOSS.
This document is the result of having some experience with SharePoint, random reading and some strong distillation of much more comprehensive resources on the topic (see sources below).
Web Part Intro
SharePoint web parts are ASP.Net server controls that are placed in web part zones of web part pages that reside on a SharePoint site (whew!). I’ve heard them described as widgets for ASP.NET. Consider them as a way to package functionality for SharePoint users.
Some web parts are included in WSS when you buy Microsoft Server 2003; WSS comes with Server 2003. Many more web parts are available when you buy MOSS in addition to WSS. Developers are able to create custom web parts that run on WSS and MOSS. However, custom web parts developed with the more extensive MOSS libraries will only run on MOSS.
Web Part Security
The fundamental security principle at the heart of web part security is adhering to a policy of least privilege. The SharePoint administrator needs to protect the local server resources by restricting the operations of web part code (i.e. assemblies), regardless of whether the code is operating with malicious intent or not. Developers should ensure that their web parts only have access to those resources required to perform their operations. The developers are really in the best position to make this call.
Establishing Trust
The ASP.Net Common Language Runtime (CLR) provides for code access security (CAS) with respect to web parts. CAS is also referred to as policy-based security, and employs a mechanism that restricts the operations allowed to be run by an application based on a user configurable policy that is enforced by the CLR. As a result, the reach of web parts into local resources can be controlled; managing risk. Java uses a similar mechanism.
The fundamental concept behind CAS is associating a level of trust with a web part. There are five trust levels that can be assigned within ASP.NET (full, high, medium, low, minimal) and two additional, extended levels provided through WSS (ww_medium, wss_minimal). If that web part attempts to perform an unauthorized action against local resources, the CLR will throw an exception. By default, SharePoint comes with a policy that invokes wss_minimal, allowing slightly more liberty than ASP.Net minimal, but still quite restricted.
There are a few ways to manipulate trust levels or potentially turn off CAS all together. You can raise the entire trust level within a SharePoint instance. You can deploy your web parts in the Global Assembly Cache (GAC). You can create your own policy.
Raising the trust level for a particular SharePoint instance is accomplished by editing the web.config file and deploying your web parts to the \bin directory. All web parts in /bin will have the same level of trust. This is easy to do, but you may not want to have all web parts to have the trust.
Deploying to the GAC is accomplished by placing your web parts in the \windows\assemblies. All web parts deployed to the GAC have a trust level of full and are available to all instances of SharePoint within the WSS implementation. Installing to the GAC should be done with consideration given the principal of least privilege. Web parts in the GAC will more than likely be running at a higher level of trust than required, as well as being accessible more widely than necessary.
Creating your own policy allows you to define the trust level on a web part by web part basis. The level of trust would only be limited by the permissions of the user running the web part. This method provides the highest level of granularity, but requires the most effort on your part (no pain, no gain!). To modify trust in this manner, the recommended approach is to include a CodeAccessSecurity section in the manifest.xml file included in the deployment package (.wsp) of your web part.
Sources
A Developer’s Introduction to Web Parts, Andy Baron, MCW Technologies, LLC
http://msdn2.microsoft.com/en-us/library/ms916848.aspx#sharepoint_northwindwebparts_topic20
Microsoft Windows SharePoint Services and Code Access Security, Maurice J. Prather, Suraj Poozhiyil, Andrew M. Miller, Microsoft Corporation
http://msdn2.microsoft.com/en-us/library/ms916855.aspx
