The .NET Framework provides Code Access Security (CAS), which is a security mechanism that complements Windows access control and .NET role-based security. Both of these are based on the identity of the user who is executing the code. CAS lets you control the permissions the executing managed code has based on evidence associated with the executing code. CAS is a fairly complicated topic that many developers do not even know exists, or if they do, they do not really understand how it works. (For a deep understanding of Code Access Security, including how it works, how to configure it, and how to programmatically invoke it, I recommend Programming .NET Components, Second Edition, by Juval Lowy, O'Reilly & Associates, 2005.)
Evidence is based on either the identity of the code itself or the launch location of the code. The code's identity is determined by one of several forms of code identity that are embedded in the assembly manifest at compile time. These forms of identity include a hash of the assembly contents, an assembly strong name, or a publisher certificate. The location the code is being executed from can be determined by the .NET runtime based on the path used to load an assembly, and can be associated with a local machine directory, URL, site, or zone.
CAS is driven by security policies that can be administratively configured through the .NET Configuration tool or set programmatically. A complex schema of security objects drives the application of CAS by the runtime. Each machine has several security policies defined for it. Each security policy is composed of a collection of code groups, and each code group is composed of a form of evidence (also called membership criteria) and an associated permission set. Each permission set is composed of a collection of individual permission types, which correspond to the discrete operations or resources that you want to protect, such as the file system, user interface, security capabilities, or the registry. For each permission type, there are fine-grained options that you can control. For example, you can control what specific set of URLs an application is allowed to access for a permission of type WebPermission.
For applications that are not launched through ClickOnce, CAS evaluates the evidence available for an assembly as the runtime loads it. It compares the evidence for the assembly against each code group's membership criteria (form of evidence associated with the code group). If the evidence presented by the assembly meets the code group's membership criteria, the assembly will be granted the code group's permission set. The runtime follows this process for all of the code groups in all of the policies on the system to come up with a final set of permissions that the assembly is granted for execution. As the code in the assembly is invoked, security demands can be made programmatically (typically by Framework assemblies) that ensure that the assembly and all of its callers have been granted the required permission for the operation or resource access that is being performed. If the assembly itself or any of the calling assemblies do not have the demanded permission, a security exception will be thrown.
By controlling the configuration of CAS, you can explicitly grant or deny permissions to any assembly on a machine for various operations and resources. For example, you can configure a server machine so that only .NET Framework code and code signed by your development organization's strong name are allowed to run on that machine. By doing so, you can ensure that if any other managed assemblies make it onto that server somehow, they will be unable to run unless an administrator intervenes and grants those assemblies a set of permissions.
When you install .NET, there are a predefined set of CAS policies and code groups installed on the machine. The built-in code groups are all based on the location that code is executing from. By default, any assemblies installed on the local machine have full trust (unrestricted permissions). This corresponds to the My Computer CAS zone. If assemblies are loaded from somewhere other than a local disk, the runtime can evaluate the path used to load the assembly and will compare it to the membership criteria of the other code groups. The other built-in code groups include ones for paths that evaluate to the LocalIntranet zone, Internet zone, Trusted Sites, or Restricted Sites. The LocalIntranet and Internet are the most common other security zones applied, based on the path to the assembly being loaded. The Trusted and Restricted Sites zones are based on URLs configured through Internet Explorer security settings.
This article is excerpted from Smart Client Deployment with ClickOnce: Deploying Windows Forms Applications with ClickOnce by Brian Noyes (Addison-Wesley Professional, Microsoft .NET Development Series. ISBN: 0321197690).
