Code Access Security (CAS), the security model that's part of the .NET Framework, has been around for a while, but it is often dismissed by ASP.NET developers. ??why is this??-cca However, it is an important technology that both SharePoint administrators and Web Part developers should strive to understand. If you want to deploy Web Parts in your Microsoft SharePoint environment, CAS can help you maintain a secure SharePoint portal. This is true whether you've developed the components to be deployed internally or whether you've purchased them from a third party.

This article is for IT administrators, SharePoint site architects, and Web Part developers who want to better understand how to use CAS in their environments to ensure Web Part security. You'll get the basics of CAS technology, Web Part installation options, and the low-down on some real-world deployment issues.

While CAS has been around since ASP.NET 1.0, it meant very little to developers and administrators until the release of ASP.NET 1.1. This is because, prior to the later version, everything ran with unrestricted permissions under what is known as “full trust.” The concept of role-based security was essentially in play only in that code permissions would defer to the permissions of the user running the program.

CAS became truly useful with the advent of ASP.NET 1.1 due to the ability to configure an application to run in a partially trusted environment. Developers could then give code specific permissions to control what type of actions it was able to perform and what resources it could access. This was enforced irrespective of the permissions of the user running the program.

Why should I care about this?

The ability to limit the reach of applications through the concept of CAS is a powerful tool for both administrators and developers. You are probably asking yourself, did he really say “developers”? Isn't this just the kind of thing that system administrators love so they can pile requirements on developers in order to bend them to their twisted bidding? Well, no. In fact, meeting the demands of defining the appropriate CAS level for an application should originate from the developer -- not system or site administrators. Developers are in the best position to identify the minimum set of permissions their code will need.

Turning code loose on a server and letting it run with full trust is not only bad practice, it also robs a developer of some important benefits. Let's say an issue arises indicating a corrupt system registry on a server that your Web Part was deployed to earlier in the week. You can tell by reading the e-mail chain being sent around that IT is starting to point the finger your way for scant evidence other than the unfortunate timing of your installation. With a custom CAS policy in place, you can quickly point out that your Web Part is configured to run without permissions to access to the system registry or write to the file system, thus sending them on their way to look for other possible culprits.

Developers can also benefit from CAS by using it as a mechanism to find bugs. Turning on or off specific permissions can help identify where a problem is occurring. Internal developers can also do strange things in their code too, and although malicious intent may not be there, buggy code can create problems. CAS ensures that code can only do certain things and can prevent a process from being usurped by another that may have a more wicked intent.