All the managed code is subject to code access security. It
is granted a set of code access permissions that determines what resource types
it can access and what types of privileged operations it can perform. The
Microsoft .NET Framework security system uses evidence to
authenticate code to grant permissions. Evidence is used by the .NET Framework
security system to identify assemblies. Code access security policy uses
evidence to help grant the right permissions to the right assembly. Evidences
can be classified of 2 types. Location related evidences and Author related
evidences. The location related evidences can have a URL the assembly is
obtained from or a directory the assembly is obtained from.
Code access security policy is configured by administrators
and it determines the permissions granted to the assemblies. There are four
types of policies identified for code access security.
·
Enterprise - Used to apply Enterprise wide policy.
·
Machine - Used to apply machine level policy.
·
User - Used to apply Per-user policy.
·
Application domain-level policy - ASP.NET code access security
process is an example of Application domain level policy.
Execution of an Assembly by loading it into Application
Domains
An assembly is said to be domain-neutral when its code can
be shared by all domains in the process. The runtime host decides whether to
load assemblies as domain-neutral when it loads the runtime into a process.
There are three options for loading domain-neutral
assemblies:
Load no assemblies as domain-neutral, except Mscorlib, which
is always loaded domain-neutral. This setting is called single domain because
it is commonly used when the host is running only a single application in the
process.
Load all assemblies as domain-neutral. Use this setting when
there are multiple application domains in the process, all of which run the
same code.
Load strong-named assemblies as domain-neutral. Use this
setting when running more than one application in the same process.
In case of loading assemblies as domain-neutral, memory use
and performance are at stake. The performance of a domain-neutral assembly is
slower if that assembly contains static data or static methods that are
accessed frequently. Access to static data or methods is slower because of the
need to isolate applications. Each application domain that accesses the
assembly must have a separate copy of the static data or method to prevent
references to objects in static variables from crossing domain boundaries. As a
result, the runtime contains additional logic to direct a caller to the
appropriate copy of the static data or method. This extra logic slows down the
call.
An assembly is not shared between domains when it is granted
a different set of permissions in each domain. This can occur if the runtime
host sets an application domain-level security policy. Assemblies should not be
loaded as domain-neutral if the set of permissions granted to the assembly is
to be different in each domain.