Code Access Security in MOSS

What is Code Access Security and Why Does it Exist?
Nowadays, most software is created by combining components from various sources. Some programs can even be extended at runtime during execution with contemporary component For example, MOSS can be extended with a new WebPart, exposing different functionality. However, not all parts of a composed WebPart are necessarily equally trusted across the board. For instance, a WebPart, when activated within MOSS, may not be trusted to create backend data connections while the site itself does have permission to do so. Nonetheless, all portions of the WebPart and site, whether they are trusted or not, share the same process and memory when executing on the server to serve to the client.

Introduction to Code Access Security Architecture

Code Access Security (CAS) is a subject that although many traditional .NET developers don’t have to deal with day by day, SharePoint developers encounter continually. Although for some this may appear to be nothing more than a constant nuance, the features that build code access security allow you to define security mechanisms that exist at varying levels, restricting several actions that could otherwise be malicious towards your environment. The answer is probably no. Many permissions however will be deemed acceptable depending on the needs of the organization. The administrator is responsible for defining a security policy to represent choices such as these. At a high level, the administrator needs to ask themselves the following two questions:

  1. Should our SharePoint WebPart executing from the intranet be running with different permissions than WebParts that are running on a perimeter deployment?
  2. For every SharePoint WebPart code group, which permissions should be granted to code in that arbitrary group?

For every SharePoint WebPart with a code group, there will likewise be a related permission set. The SharePoint administrator will have to make a crucial decision as to what WebPart code falls into what arbitrary code group, and what those related permissions are relating to that code group. This in turn is called classifying the code group, in essence, giving it a related arbitrary group which will define the associated permission. By creating these different logical groups that different code can run under, it is possible to further control what the SharePoint WebPart code can touch, execute, and ultimately, how the SharePoint WebPart will effect the overall collaboration environment.

The primary base class library of that Microsoft Office SharePoint Server builds upon makes extensive use of the Code Access Security system to ensure that partially trusted code can be executed in a secure manner whereby only trusted code can run. In turn, this base class code that Microsoft Office SharePoint Server builds upon for WebParts will run in two major manners:

  • WebPart imperative
  • WebPart declarative

Using these differentied permission sets, it is possibly to do granular checking of how arbitrary WebPart code can be run. These permission “groups” will make explicit demands which will clarify where permission checks have to be performed when the WebPart is executed to make sure partially trusted code will not violate the permissions granted to it in the security policy (related to the partially trusted callers attribute, something that has become a rather important concept in the new version of SharePoint).

A Microsoft Office SharePoint Server trusted WebPart library (the assembly that will talk to the description file) can rely on this safety feature to protect the resources it houses, as well as environmental resources that it will touch. The principle that is trying to be established through this concept is if a WebPart is executing an operation that could be consider sensitive, perhaps touching susceptible operational resources, there will be a system of checks and balances. This check will, in aggregate, make the overlying decision as to if the WebParts requested feature is allowed by performing an overall interrogation of the call stack.

Code Access Security, SharePoint, and Code Permissions

WebPart code access security (CAS) in relation to Microsoft Office SharePoint Server defines aggregate WebPart code access rights by means of permissions. A WebPart uses the concept of permissions as a first-class object. This first-class object in turn will represent a right to execute or access certain operations or resources.

Example of First-Class Permission Objects
When building a SharePoint WebPart, you may need to access certain files, and afterwards, execute an operation on that local server file. This is considered a sensitive resource, since we are accessing a file that is located on the server. Therefore, by instantiating A FileIOPermission object for the WebPart instance, it is possibly to represent the right to perform arbitrary operations on arbitrary files, depending on what the WebPart is going to do.

Permission objects actually represent sets of more primitive permissions, and it is always possible to take the union or intersection of two permission objects of the same type. A PermissionSet object groups permissions of different types.

Code Access Security Evidence

Permissions are assigned to SharePoint WebParts based on evidence.
A piece of evidence can be many things:

  • location where the assembly was downloaded from
  • the code publisher that digitally signed the assembly

For many SharePoint developers, the subject of creating a custom security policy is fairly normal, since there are high levels of code access security built into the SharePoint framework. This security policy can be modified by the end user. Once the security policy is defined, this will map the evidence to the related permission set (maps evidence to permission sets). Once this permission set is defined for the SharePoint WebPart, it is known as a static permission set for the WebPart assembly.

Since WebParts can access various things, and likewise perform diverse operations (such as printing something, or accessing objects out of the file system), the concept of permission classes are very important to the SharePoint developer. All sensitive actions that a WebPart can do which is considered protected is considered a permission class in the .NET framework. Permissions can be instantiated and configured to represent the idiosyncrasies of the resource.

Example Of Permission Class For Web Part File I/O Permission
The permission class representing the File system, is FileIOPermission. This can be created and have a set of readable and writable paths added to it.

One can easily control these relevant permission settings:

FileIOPermission permission = new FileIOPermission( PermissionState.Unrestricted )


Or just as easily specify a harmful object for denial:



These demands and denials are present in the .NET framework base classes.

The Common Language Runtime for the .NET framework which WebParts will execute under will preserve for all threads an associated dynamic permission set. This will embody the tangible access rights that the thread has at this point in its execution.
The dynamic permission set is not characterized unambiguously in the Common Language Runtime. Instead it is computed by stack inspection. It defaults to the intersection of the static permission sets of all code that is currently on the call stack, but trusted WebPart code can influence the stack inspection process.

Code Access Security, Evidence, and SharePoint
Every binary that in turn will provide the backend business logic for SharePoint WebParts, can be considered as presenting a set of evidence.
Evidence includes:

  • public keys
  • presence of a hash
  • source directory
  • zone

Every SharePoint WebPart code group has a set of membership conditions. These membership conditions must be satisfied if the WebPart code is to wants to bind as a member of the group. It is through the examination of the above bulleted pieces of evidence that the membership conditions are inspected and evaluated.
Evidence is an central concept for both SharePoint administrators and SharePoint developers. Administrators can configure security policy across three levels

  1. Enterprise
  2. Machine
  3. User

This concept of a multi-tired policy system enables certain policies to be implemented across the entire enterprise or for precise machines and users. In this, each policy level can add explicit restrictions, but a SharePoint administrator or developer can make restrictions in a finely tuned way that allows definitive access over the SharePoint environment.