Last week I spoke at the Rocky Mountain (Denver) SharePoint User Group and we talked about CAS. CAS is great because it limits what your code can do. For example-- you can know that my code won't compromise x because it doesn't have permission to even talk to type x. It can be difficult for  developers that aren't familiar with CAS to grasp the concepts. Typically, your project CAS requirements can be determined early on in the project lifecycle, and don't change often over the course of development. For example-- the CAS policy for NewsGator Social Sites hasn't changed since version 1.0 over a year ago. We also NEVER ever manage CAS manually-- we add the security permissions to the WSP solution package, and let SharePoint manage CAS for us.

But how do you determine what CAS settings you need? To start off with, always start off by running SharePoint in minimal trust. Also, enable debugging and the full call stack in web.config. The SafeMode node has a CallStack attribute that you'll want to set to true. With this, you'll get the full yellow screen of death rather than SharePoint's happy-happy joy-joy blue screen of "an error has occurred".

With this set up-- when your code encounters a CAS error, you'll get a message similar to this:

SecurityException: Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed. [Full call stack follows... great reading, but you'll have to find your own. Really, it's not that hard to find!]

With this, we know that we need the CAS permission "System.Security.Permissions.SecurityPermission". Most permissions are conveniently located in this namespace, BTW. With this information, we can easily create the following IPermission entry in the manifest.

However, there are still more attributes you'll need to get the full/required trust that the permission can define. I don't think I have a GREAT answer for this, but I use Reflector to get that info. Also, you can do a simple search and find the syntax-- either in MSDN, exising CAS settings in the permission files in the 12 hive, particularly \12\config\wss_minimaltrust.config, or with the google. The best way to do it is to reference the type that threw the exception to see what it's CAS requirements are. For example, I was trying to use the System.Diagnostics.Process class in some recent debug code. The error message I got from the stack trace wasn't too complete, it just showed that the security demand failed. So I looked at Process with Reflector, and that shows the CAS that you need to work with Process.

[PermissionSet(SecurityAction.LinkDemand, Name="FullTrust"), PermissionSet(SecurityAction.InheritanceDemand, Name="FullTrust")]
public class Process : Component {/* class here... */}

It turns out that Process requires full trust to run... so it isn't going to run at all with partially trusted code!

Back to my earlier example-- the full permission that I needed in my test case follows:

<IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
        version="1" Flags="ControlThread, UnmanagedCode" />

One thing I like to do is keep a reference of common CAS settings handy. Because although I LOVE typing in XML, there's more interesting XML to hack than CAS. So keep a CAS reference handy-- here's a relatively complete sample CAS entry for one of my commercial projects. Note that it's for an unrestricted WebPermission to make network calls-- you could further lock that down to a specific URL-- and it's also for the required permission set for using SPSecurity.RunWithElevatedPrivileges.

<PolicyItem>
      <PermissionSet class="NamedPermissionSet" version="1" Description="Permission set for foo" Name="foo">
        <IPermission class="AspNetHostingPermission" version="1" Level="Unrestricted" />
        <IPermission class="SecurityPermission" version="1" Flags="Execution,ControlThread,UnmanagedCode,ControlPrincipal" />
        <IPermission class="System.Security.Permissions.EnvironmentPermission" version="1" Unrestricted="true" />
        <IPermission class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
            version="1" ObjectModel="True" Impersonate="True" UnsafeSaveOnGet="True" />
        <IPermission class="System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Unrestricted="true" />

      </PermissionSet>
      <Assemblies>
        <Assembly Name="foo"/>
      </Assemblies>
</PolicyItem>

Related reading: If you don't know what the WSP solution package deployment is-- that is a prerequisite to CAS management. Take a look at the online docs or at codeplex projects such as STSDEV or WSPBUILDER for better ways to build solution packages, or use my old-school VS project template from codeplex.com/sharepointsdk.

SHAMELESS PLUG: Want to know more about CAS? Chapter 10 of Inside Microsoft Windows SharePoint Services 3.0 has a great reference on CAS, and more great documentation on the WSS security model.

Check it out here: http://launchpad.enterprise2conf.com/node/36. It's a great demo of SocialSites embedded in a cheesy The Office spoof. (Yeah, that's my code they're using!)

RunWithElevatedPrivilege drops the identity of the code to the process user, which is either the current user in a console application or the application pool if run in the web application. It requires a ton of CAS permissions and is generally overkill for what you need to execute as system. And did I mention-- the Microsoft support policy on it is a little fuzzy? It can also lead to bugs as objects cannot reliably be passed into the delegate-- especially constructs like the SPUser object. (There are some VERY obscure bugs that can occur when passing references across those boundaries!)

A better way to do perform system actions is to impersonate the SHAREPOINT\system account. Impersonation is a concept that is built into the object model, but is underutilized by developers.

The SPSite object takes an SPUserToken object in its constructor in order to support impersonation. (This does require Impersonate="True" for the Microsoft.SharePoint.Security.SharePointPermission permission class). You can impersonate any user when creating the SPSite context-- so to get the system account, just use the magic system account "SHAREPOINT\system".

Here's a code sample of SYSTEM ACCOUNT impersonation.  The SYSTEM ACCOUNT uses the login name "SHAREPOINT\system" internally while it will use the process identity (usually that means the application pool identity, but it could be the service identity if a task was run as a timer job) when making external network calls. Note that the account is abstracted, and when a request comes into the system AS this account it will take on the identity of SYSTEM ACCOUNT.

Here's the code sample. Grab a user object, and then grab the SPUserToken for impersonation:

var superman = SPContext.Current.Web.AllUsers[@"SHAREPOINT\SYSTEM"];
var superToken = superman.UserToken;

using (var site = new SPSite(SPContext.Current.Web.Url, superToken)){
    // This code runs under the security context of the SHAREPOINT\system
    //  for all objects accessed through the "site" reference. Note that it's a
    // different reference than SPContext.Current.Site.

    using(var elevatedWeb = site.OpenWeb()){
        // Perform actions as SYSTEM here
    }
}

Because the thread identity hasn't changed, this will produce more stable code in most circumstances, although you should be aware that ONLY objects that are referenced from the elevated site context will run as system.

//Updated on 5/22/08 -> the correct method to get the system user is with the AllUsers property of the SPWeb object, since EnsureUser requires management permissions anyway...

I upgraded my laptop this week to the HP tx2000—and it runs Server 08 x64 flawlessly. Everything works flawlessly on 64bit Server, including the webcam, wireless, tablet functionality, and Bluetooth. If you’re looking for a small laptop (12”) that’s speedy and runs server I’d recommend this one, and it’s only around $1200 pimped out from HP with the 2.4ghz Turion (I also added 4gb ram and a 72000rpm drive from my last notebook).

For writing code-- NOTHING beats un-virtualized development. But VMs for testing and staging are darn handy, and the virtualization support in the Turion chip is excellent. My theory: virtualization is a crutch for environments that can't be scripted!

Buy my old Laptop (HP tx1120us) with Server 2008 ($800)

I'm selling my old laptop-- I'll even include Server 2008 pre-installed with all the drivers if you supply the MSDN license. It's an HP tx1120us tablet PC with 2gb RAM (you can upgrade the RAM to 4gb for $75 @ TigerDirect.) It runs a 64bit dual core AMD Turion (with hardware virtualization support) and comes with Vista Home Premium. Comes with a built in webcam, wireless G, gigabit ethernet, stylus, fingerprint reader, remote control for Media Center, and a 12" swivel touch screen display. If you're interested email me at buymylaptop@danlarson.com. It's under warranty until June 3 and you can extend that. It runs Server 08 BEAUTIFULLY.

I've got an official page for the book-- and we've got a formalized title as well, "Developing Service-Oriented AJAX Applications on the Microsoft® Platform"

While there's not much there yet (no Amazon links yet... ), check it out: http://www.microsoft.com/MSPress/books/12793.aspx

Here's how the book is described (and it's pretty accurate!)

Your essential guide to building Rich Interactive Applications (RIAs) using Microsoft technologies

Delve into the fundamental architectural principles and techniques for developing service-oriented AJAX applications for the enterprise. This guide offers a code-heavy, example-based approach to learning how to write a modern services API and an AJAX front end that can easily be extended, reused, and integrated by third parties.

Focusing on Microsoft technologies and enterprise servers, including Microsoft SharePoint® Server 2007, ASP.NET AJAX, and Microsoft .NET Frameworks 2.0, 3.0, and 3.5, this book walks you through a client-centric UI architecture programmed against an XML service-oriented backend. Topics include the Microsoft AJAX Library, Web services and an XML API, client-side XSLT, JavaScript AJAX communication, and integration with Microsoft servers.

The book does not attempt to be an exhaustive reference, but focuses instead on fundamental architectural principles and guidance.

Also, the expected street date is 11/12/2008, but it might ship sooner:)