Jan 272007
 

UPDATE: 1/28/07. The following techniques have been applied to the SharePoint Ajax Toolkit in Release 1.01 and changeset 17278+, which can be used as a reference implementation of CAS for WSS. 

Once again I find myself blogging, when I really should be working. I’ve got a hard deadline on this chapter for MSPress, and yet I find it easier to blog than to use Microsoft Word. Blogging can be a great cure for writers block, and since we’ve had some preorders (thank you Tony) this is my little way of sneaking you content before the publishing process is complete, as well as give you a chance for some input to the final manuscript.

I’ve spent the last few weeks on the Security chapter for Inside Windows SharePoint Services 3.0 and am just wrapping up the chapter. I’d like to share a few observations, theories and recommended practices, and would also like to call for feedback and stories from your employers and clients. We usually skip dealing with CAS since it can be difficult, so it’s my goal to make dealing with CAS simple and a standard part of WSS development.

These all have to do with Trustworthy Computing. "The security of our customers’ computers and networks is a top priority, and we are committed to building software and services to better help protect our customers and the industry."

So now, let’s talk about Code Access Security. Here’s some content straight out of the book. Code Access Security, commonly referred to as CAS, defines the execution permissions granted to a piece of code that runs in a partially trusted location. A partially trusted location does not fully trust the code that it contains, and creates a restricted security context to isolate its code from the rest of the system. Because the partially trusted location runs with restrictive permissions, it limits the attack surface of the system and is the most secure location to run code from. This allows code to run in predefined security contexts without risk of compromising critical personal or corporate data. The website bin directory is a partially trusted location in which Code Access Security is enforced. Because of this fact, it is the preferred location to deploy Web Part applications. Note that the least trusted location is the most secure place to run your code from. The global assembly cache (GAC) is a fully trusted location in which CAS is not enforced, as is the _app_bin location. The _app_bin location is a special location for WSS infrastructure components that should not be used for custom code. Certain WSS component such as Feature Receivers and Event Handlers must be deployed to the GAC however, so you may wish to create separate assemblies for Web Parts in order to enable deployment in the bin directory.

Now, some observations and theories:

My first observation is that your average dot net developer completely ignores CAS since ASP.NET runs in full trust mode 99.999 percent of the time, unless you are talking specifically about sharepoint apps. I know that a majority of past and present employers/clients don’t really get or use CAS. We’re also talking about major enterprises, not just small mom and pop shops.  

My second observation is that most SharePoint developers also ignore CAS and simply put the code in the GAC or run in Full trust. We usually say something like, "What do you mean the request for Microsoft.SharePoint.Security.SharePointPermission failed? I’ll just switch to Full trust." Yes, I’ve been guilty in the past of forcing customers to run in Full trust. (Shame, shame, shame. But they listened!)

My first theory is that sharepoint developers tend to think of CAS as a requirement for code rather than a way to secure their code. For the most part, SP Developers think of CAS only in terms of "we have to do THIS in order for our web part to run. What a PITA!" We generally don’t think of CAS as a good thing to secure our code, but rather a way of enabling it to bypass SharePoint’s security.

So here’s my conclusions and recommendations, after doing a LOT of research for this chapter.

First of all, the reason this is critical in SharePoint vs.ASP.NET in general is that there are typically a LOT of components running in the Portal. A lot of these components also access critical and sensitive enterprise data, particularly when talking about MOSS deployments, and a lot of these components also come from vendors.

Your code should not be trusted to do anything more than you intend it to do. So lock it down with CAS– run it in minimal trust and apply only the permissions you need for it to run.

The website should be run in WSS_Minimal trust. This includes derived trust levels generated by WSS through explicit permissions set in Solution Manifests.

Your code should apply security demands where appropriate to ensure it isn’t used to compromise security. If you’ve granted a trust level to your assembly, a security demand will enforce that an untrusted assembly isn’t using your component as a trusted backdoor.

Web application code (Web Parts) should ALWAYS be installed to the bin directory. Since GAC deployment will place an assembly in the full trust code group for WSS, only run web components (web parts, web services and http hapdlers) from the bin directory.

Security should be auditable. any changes to the CAS security policy should be auditable. If you require permissions for your assembly, you should document it and make it auditable. (This also makes a great argument for some level of shared source code for SharePoint components.) 

I’ve got a little work to do to convert the SharePoint Ajax Toolkit to these standards. For example, included in the web part assembly is the Feature Receiver code. This requires GAC deployment, forcing the entire assembly into full trust. Instead, the Feature receivers need to be placed into a new assembly and deployed to the GAC while the web part code goes to the Bin. The SharePoint AJAX toolkit requires very little trust to run except for the SharePointPermission since it simply contains a JavaScript library and renders simple html and JavaScript references.

The good news is that SharePoint Solutions make this all VERY easy to manage.This is a concept I’m stressing in the book and will blog about as I have time– CAS should be managed exclusively from the solution manifest. Solution Packages are the supported and recommended way to set custom security levels. Other than switching the trust level during initial development, editing and managing security manually in configuration files is not maintainable at large scales and is not a recommended practice.

If you have code security policies you’d like to share (in the form of anonymous examples), please send them to me. My email address (I get so much spam it’s ridiculous) is daniel at portal builder dot org. Also welcome are any questions about CAS, solution packages and security. Since this article has been more about the concepts of CAS and security, I’ll try to get some solid how-to examples posted as I get feedback.

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>