I certainly hope that nobody would argue that security is one of the most important architecture and design issues within any application. The .NET Framework manages security through the Common Language Runtime (CLR). The CLR is responsible for ensuring that applications provide a set of verifiable evidence. This evidence is then compared against the current defined security policy and then either granted or denied runtime permission.

Evidence comes in a variety of forms. The most common are either digital signatures or code origination. Additionally, evidence may include a set of custom types that are meaningful to the specific application. Both assemblies and application domains are able to receive specific security grants based on the type of evidence they can provide.

Examples of evidence types:

It is actually the responsibility of the application host to maintain the specific evidence. A trusted host is defined as any host that has sufficient permission to provide the Common Language Runtime with the necessary required evidence. The System.App.Domain class is responsible for providing the application domain functionality used by hosts.

Examples of supported hosts:

Trusted application domain hosts are able to present information about an assembly or application domain to the runtime. The runtime then uses this information to evaluate the enterprise, machine and user policy to derive a set of permission that granted to the assembly or the application domain. If for any reason the trusted application domain host isn’t able to receive permissions or provide evidence, the assembly or application domain automatically receives the same permissions granted to the host.

In most cases the .NET runtime receives evidence about specific assemblies from either a trusted application domain host or directly from the loader. Code origination is an example where the trusted application domain host is on capable of determining the required information. In all cases trusted application domain hosts are allowed to override specific types of evidence provided by the loader and can instead provide their specific evidence type.

Other types of evidence such as a digital signature are inherited directly from the code itself and can come from either the loaded or trusted application domain host. It is the job of the runtime to validate each assembly’s digital signature when the code is loaded. If the digital signature validates the trusted application domain then passes this as evidence to the runtime’s security policy. Assemblies or trusted application can also provide custom evidence as a resource that is considered part of the assembly.

It is really the job of the runtime policy mechanism to use the evidence provided by both the trusted application domain hosts and assemblies to determine the code section member within the code group. As the runtime evaluates and grants trusted code levels access is granted to protected resources. For example, based on the specific code group and access rights granted this may include the ability to access the local disk drive. One of the easiest ways to understand the various security levels is to take a look at the zones concept of Internet Explorer. Like Internet zones, Framework applications that run from the internet don’t receive the same level of trust as those that run from the local computer. Applications installed locally are by default granted the highest level of access and are automatically enabled to access local protected resources like the disk drive. Application run from the Internet are by default restricted from access local protected resources.

In the majority of cases the default security policy provides an adequate level o protection for computers. Although, there may be cases where an Administrator may need to extend the security and grant additional rights. The Framework provides the .NET Framework Configuration Management Console (Mscorcfg.msc) or a command line batch utility Caspol.exe to alter the currently defined security policy. For example, using Caspol.exe the following command enables smart client application to run through a URL.

caspol -pp off -addgroup 1 -site MySite FullTrust -name Microsoft.CustomForms.SmartClient

Both Caspol.exe and the .NET Framework configuration tool provides a wide variety of switches and options that are documented pretty extensively within the Framework document. These are definitely worth printing out and keeping close as you design and architect your applications.

It is really the responsibility of every Developer and Architect to understand security within the .NET Framework. Without a thorough understanding how can any application truly be considered secure? This was a fairly brief overview of the security within the .NET Framework; I strongly encourage you to explore it further. Below are some of the links that I have found the most help and information in.

An Overview of Security in the .NET Framework

http://www.msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnnetsec/html/netframesecover.asp

Microsoft Security Developers Center

http://www.msdn.microsoft.com/security/

Defend Your Code with Top Ten Security Tips Every Developer Must Know

http://www.msdn.microsoft.com/security/default.aspx?pull=/msdnmag/issues/02/09/securitytips/default.aspx

10:56:11 PM